sca-assembly message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [sca-assembly] [Issue 253]: (1.2) Must a global domain channel bedeployed before it can be used?
- From: Mike Edwards <mike_edwards@uk.ibm.com>
- To: sca-assembly@lists.oasis-open.org
- Date: Tue, 15 Feb 2011 10:55:20 +0000
Folks,
Some comments as <mje>...</mje>
Yours, Mike
|
|
Dr Mike Edwards
| Mail Point 146, Hursley
Park
|
|
STSM
| Winchester, Hants SO21
2JN
|
SCA & Services
Standards
| United Kingdom
|
Co-Chair OASIS SCA
Assembly TC
|
|
|
IBM Software Group
|
|
|
Phone:
| +44-1962 818014
|
|
|
Mobile:
| +44-7802-467431 (274097)
|
|
|
e-mail:
| mike_edwards@uk.ibm.com
|
|
|
|
|
From:
| Anish Karmarkar <Anish.Karmarkar@oracle.com>
|
To:
| sca-assembly@lists.oasis-open.org
|
Date:
| 15/02/2011 02:01
|
Subject:
| Re: [sca-assembly] [Issue 253]: (1.2)
Must a global domain channel be deployed before it can be used? |
<vdR>
My words weren't intended to be too similar to your original, but I certainly
missed the question of the application composite being deployed containing
the definition of an auto-deployed channel. My apologies. I
don't see anything for an auto-deploying runtime to do in the case where
the GDC is defined as part of what is being deployed. But again,
if the composite doesn't contain the GDC definition, we're back to either
rejecting it or auto-deploying it, aren't we? Am I missing something
here?
</vdR>
We define three states for SCA: installed, deployed and running. We do
not require error checking (such as whether a producer refers to a global
channel that has been deployed or not) in the deployed state (but a runtime
could). WRT whether we only have only two options: rejecting it or auto-deploying
it when the composite doesn't contain the global channel definition --
we actually have three options. The third one being you allow the deployment
but you don't run anything. Before you run anything, you require that all
the expected deployments (including deployment of global channels through
a separate composite) get done.
<mje>
The spec actually allows
things to run even if there are unsatisfied references. What must
happen is that an error is raised if ever a running component tries to
use a reference that is unsatisfied..
I can envisage the same
being done for event processing - it would only have meaning for component
producers, of course - ie where the producer is configured to send events
to a channel that is not yet deployed.
</mje>
This problem is no different than references in a deployment composite
that refer to services that happen to exist at the domain-level only through
the deployment of a different composite.
<mje>
Thank you for putting it
so clearly.
My concerns with auto-creation
surround this possibility of deployment taking place as a series of steps,
rather than as a "single big bang" - and with the question of
what happens at the completion of each step.
I am concerned with the
case where the Domain level channel is there *somewhere* in the deployed
contributions but where it has not yet been deployed. Allowing auto-creation
in these circumstances is problematic, if auto-creation occurs before the
deployment of the Domain level channel.
</mje>
-Anish
--
On 2/14/2011 4:21 PM, Danny van der Rijn wrote:
<vdR>.. responses like this ...</vdR>
On 2/14/2011 3:09 AM, Mike Edwards wrote:
Danny,
Responses as <mje>...</mje>
Yours, Mike
|
|
Dr Mike Edwards
| Mail Point 146, Hursley
Park
|
|
STSM
| Winchester, Hants SO21
2JN
|
SCA & Services
Standards
| United Kingdom
|
Co-Chair OASIS SCA
Assembly TC
|
|
|
IBM Software Group
|
|
|
Phone:
| +44-1962 818014
|
|
|
Mobile:
| +44-7802-467431 (274097)
|
|
|
e-mail:
| mike_edwards@uk.ibm.com
|
|
|
|
|
On 2/10/2011 2:48 AM, Mike Edwards wrote:
Danny,
I'm less about making arguments and more about trying to describe the Event
Processing ideas in the same terms that we
have already described for services in the current V1.1 specifications.
There, the spec does describe different styles of
runtime, with differing approaches to deployment and to the possibility
of redeployment.
Mike -
Let me rephrase my previous mail from "your arguments ... " to
"your questions ...". I didn't mean to appear argumentative
by my lazy choice of words :-)
I tried to point out that auto-deployment carries an implication of redeployment,
since if the runtime auto-deploys some channel
for which there is actually a concrete channel supplied by some later deployment,
then we are inevitably into the realm of
redeployment.
Again, though, I don't see the questions being centered around auto-deployment,
but about deployment and redeployment in general. Imagine, for instance
that in order to deploy some composite, I must first deploy a GDC (if we
don't allow auto-deployment). So I do so, but give it no configuration,
or any configuration that isn't acceptable to a later deployment. And
I reword your statement slightly: "... auto-deployment
carries an implication of redeployment, since if the runtime
auto- administrator
deploys some channel for which there is actually a
concrete channel different
configuration supplied by some later deployment,
then we are inevitably into the realm of redeployment. "
<mje>
Your words don't mean anything like my original ones - you've avoided the
question of how the simple case of my application composite containing
the definition of a Domain channel to deploy gets handled in the case of
a runtime offering auto-deployment.
</mje>
<vdR>
My words weren't intended to be too similar to your original, but I certainly
missed the question of the application composite being deployed containing
the definition of an auto-deployed channel. My apologies. I
don't see anything for an auto-deploying runtime to do in the case where
the GDC is defined as part of what is being deployed. But again,
if the composite doesn't contain the GDC definition, we're back to either
rejecting it or auto-deploying it, aren't we? Am I missing something
here?
</vdR>
Redeployment of a channel is at the least a tricky thing. The same
can be said of the redeployment of a service component.
Basically, what happens to anything that is "in flight"? I
was trying to address some of these issues for auto-deploy channels in
what I wrote.
I would say that GDC's don't have an analogue in the 1.1 specification
in that the 1.1 specification allows and encourages fuller encapsulation.
With the current event processing drafts there is a large area where
we're forcing components that wish to communicate outside of their component
using SCA to do so using GDCs. There is no way, for instance to assemble
two components that communicate with each other into a self-contained,
encapsulated composite.
<mje>
That you can make such a statement makes me feel that you have a very different
understanding of SCA than I do.
For me, the assembly of 2 components that communicate with each other via
a channel is "HelloWorld" level SCA 1.2.
I also don't understand the comment that "we're forcing components
... to do so using GDCs" - promotion is there for the support of controlled
exposure of dependencies and this applies to both producers and consumers.
If your concern is with this statement in the current spec: "An
SCA runtime MAY support the use of private channels [ASM????]."
ie non-Domain channels are optionally supported, then I suggest that you
raise a very specific issue to deal with that.
</mje>
<vdR>
Can you explain your "HelloWorld" scenario? Just to be
sure that you understood my point, what I'm focusing on is the fact that
I start with 2 components that are developed independently, then I assemble
them into a composite that is both encapsulated, and self-contained. In
my mind that rules out any use of GDCs. (i.e. my "forcing ...
" comment as an option that I don't like.) And since we don't
have an answer for promotion a la 227, I'm not sure how to solve it at
all, let alone with the triviality that you imply. What kind of promotion
are you using in your use case? Perhaps it's promoting one producer
and one consumer? If so, how would you do that with channels instead?
And no, I'm not talking about the private channels at all in this thread.
</vdR>
In 1.1, the redeployment question that you ask can be asked for the whole
encapsulated composite as a whole, and can be answered in ways that are
probably more self-consistent than what we can come up with for GDCs. I
understand that this is more of an argument against GDCs and/or an argument
for resolution of 227 in a way that addresses this question. I continually
find myself butting up against that issue, yet we seem to have devolved
into a pattern of ignoring the elephant in the room. This week, this
blind man grasps the 227 elephant by the tail and sees it as a 253 rope
...
<mje>
I simply don't follow.
</mje>
<vdR>
Let me take another stab here. You were asking about redeployment.
If what you're redeploying is completely encapsulated, then an implementer
could imagine various scenarios that are all defensible - all in-flight
messages are preserved; all in-flight messages are lost; etc.
I agree with you that redeployment of GDCs poses a sticky problem. My
answer to that is to use GDCs less, or delete them entirely. If we
could solve 227, I would find myself FAR less likely to want to use GDCs.
That was the point I was trying to make, albeit a bit obliquely.
My apologies for that.
Regardeless of what happens with 227, I don't see how adding this other
use case where GDCs could be redeployed puts the onus of solving the redeployment
problem on that new use case. That seems to me to be your argument.
</vdR>
Now, let me make my position clear on
"auto deployment". I think that we have similar behaviour
applied in particular to PolicySets,
with the notion that in principle an SCA Runtime can have other mechanisms
to supply these things to the Domain, other than by
deploying the contents of one or more Contributions. eg there is
the concept of PolicySets being deployed from some kind of
Repository and not necessarily being held in any application Contribution.
The current specs don't disallow this, although they
deliberately don't say much about it since the possibilities for implementation
are very broad and there is little normative to say.
What it is - is outside the standards.
While I see some analogy here, and agree with it, the presence of a reference
channel is somewhat more intrinsic to operation than the presence of a
PolicySet is, so I feel much less comfortable being vague about it. Clarity
is necessary here, whether it is to explicitly allow or explicity disallow
auto-deployment and/or define what the behavior is in the absence of a
referenced GDC.
So, I could envisage auto-deployment along the same lines. Something
that any SCA Runtime could choose to provide by some
means, but where the SCA specifications say very little. If an SCA
runtime chooses to provide auto-deployment, then it can do so
in any way it wishes.
I agree that it would be an implementation decision as to how to do it.
I would support a proposal that uses different RFC language from
the initial proposal in the JIRA. Something along the lines of
When contributing artifacts to a domain that contain references to global
domain channels that have not been previously deployed, the SCA runtime
MAY reject such contributions. Alternatively, the SCA runtime MAY
automatically create and deploy said global domain channels in this situation.
The downside for an application developer is that their application, as
contained in a set of Contributions, may not work on some SCA
runtimes, if the developer/assembler chooses not to contain one or more
Domain Channels within their composites, that they rely on
in some components within the application. If they do this, then
their application may work fine on an SCA runtime that supports
auto-creation but fail when run with a runtime that does not support auto-creation.
The same is true, I note, of PolicySets - if the
application does not supply them, there is no guarantee that they will
be made available through some other mechanism by the
SCA runtime.
See my earlier comment on the analogue to policySets. I would also
point out that the "defensive" manuever of including the GDC
in the composite may well backfire if the GDC already exists in the domain.
Are we left with another issue along the lines of do we allow deployment
of "compatible" configurations of GDCs??
However, for any SCA Runtime that DOES provide auto-creation, there is
a need to describe what happens if, due to the sequence of
deployments, some auto-created channel is "replaced" by the later
deployment of a "real channel". In my opinion, it would
be wise to
try to avoid such a situation. However, I don't see a way of preventing
this situation - perhaps this is something that you'd like to describe.
To answer whether the auto-deployed channel is any less "real"
than something else, I would offer that it doesn't matter to the runtime
where the contribution came from. So if you would find it more clear
to define auto-deployment as the process of the runtime synthesizing a
piece of contribution and deploying it, I would not object to that.
<mje>
An auto-deployed channel would be just as real as anything else, but you
seem to be sliding away from my point - IF a channel were auto-deployed
but my application happened to consist of multiple
separately deployed contributions and just happened to contain the definition
of the Domain channel in a contribution that is deployed later, then what
happens?
How does the deployer distinguish this case?
</mje>
<vdR>
I think I'm starting to see what I couldn't divine before - your use case
seems to be not that the GDC is deployed 2 weeks after the composite in
which it is used, as I had thought. Your use case is that the GDC
is deployed 30 seconds after? Is that it?
In that case, you have a problem no matter what. There is going to
have to be *something* done by the runtime to the first composite. Either
the runtime should reject its deployment, the runtime should ask "Do
you have a GDC definition in your pocket that I could deploy before I (finish)
deploy(ing) this one?" it could auto-deploy one and fail/redeploy
later, etc. There are many possibilities. But again, I don't
see how auto-deployment *creates* this problem. It is possible that
it exacerbates it, I agree. But if that's what you're worried about,
then let's answer that in the context of an issue around that, rather than
in this issue.
</vdR>
Redeployment is something that we must describe in general for all of SCA.
<mje>
OK, in that case, would you care to describe the redeployment of a Channel
and its implications?
So far I have noted that auto-creation implies redeployment. One
reason I'm not in favour of auto-deployment is BECAUSE of this redeployment
implication and its consequences.
If you can show that redeployment of a channel is a breeze, then perhaps
some of my concerns will go away.
</mje>
<vdR>
I'm fine with the idea of deleting GDCs from the draft. That would
go a long way to dealing with your redeployment issues. I imagine
that idea wouldn't go over well, though ;-)
I disagree with what you note. Auto-creation does not imply redeployment.
Sure, redeployment can follow auto-creation, but redeployment is
not required. If redeployment is your bugbear, then let's have an
issue about that, and not think that a spec without auto-creation doesn't
require dealing with redeployment.
</vdR>
Absent that, I don't see any need to describe this isolated
case. Again, I would see the auto-deployment as shorthand for deploying
a GDC with the required name and no other configuration. Assuming
that it is deployed, later deployment of a channel with the same name would
simply follow our redeployment rules. If we choose to leave the spec
silent on redeployment, we haven't made the issue any worse by allowing
auto-deployment, as redeploying a channel that was previously auto-deployed
would be exactly as implementation-defined as any other redeployment -
no more, no less.
Danny
Yours, Mike
|
|
Dr Mike Edwards
| Mail Point 146, Hursley
Park
|
|
STSM
| Winchester, Hants SO21
2JN
|
SCA & Services
Standards
| United Kingdom
|
Co-Chair OASIS SCA
Assembly TC
|
|
|
IBM Software Group
|
|
|
Phone:
| +44-1962 818014
|
|
|
Mobile:
| +44-7802-467431 (274097)
|
|
|
e-mail:
| mike_edwards@uk.ibm.com
|
|
|
|
|
Mike -
Your arguments seem to me to be more arguing against case a) than against
autocreation, as they hold for *any* more restrictive redeployment, not
just one whose previously deployed state was perhaps auto-deployed.
Auto-deployment (as I envision it) is merely shorthand for an actual deployment.
("Your composite references a global domain channel that hasn't been
deployed. Shall I create one for you and deploy it, or would you
prefer me to reject deployment of your composite outright?") Your
arguments just point out another weakness I see in the concept of global
domain channels.
Danny
On 2/9/2011 2:45 AM, Mike Edwards wrote:
Danny,
SCA Runtime "styles";
a) Reconfiguration/Redeployment is allowed
b) Reconfiguration/Redeployment is not allowed
Case b) is the simpler of the two. In this case, all the configuration
must be present when the runtime is started.
Either Domain channels are part of the configuration at this point or not
- if not, then any references to Domain
channels would either be errors (no auto-creation of channels) or would
require auto-creation of channels.
Case a) is the case where there can be separate deployment of (some) consumers
& producers and of the
channel(s) that they connect to. I note that this can only happen
for Domain level channels. Once separate
deployment is possible, then the timing of deployment matters - if Channel
deployment is later than deployment
of any of the producers that connect to the channel, then it the question
of auto-creation comes into play.
If no auto-creation is NOT allowed by the runtime, then any event produced
will have nowhere to go, which might
be flagged as an error (since the producer is configured to transmit the
events). If auto-creation is allowed, then
the events will be flowed to an auto-created Channel and on to whatever
consumers are connected to that channel.
When the Channels are later deployed into such a runtime, I assume that
the auto-created Channels get "replaced"
by the deployed versions, with whatever configuration they carry. Since
the configuration may carry Filters, this may
mean that some events get forwarded by the auto-created channel that don't
get forwarded by the specifically
deployed channel. I'm not sure what this would mean for the consumers
attached to the channel. More problematic
would be any binding and policy information attached - the binding could
indicate the need to have the channel use
some specific existing infrastructure (eg some MQ queue) - and if the intention
is that events flow to/from the existing
infrastructure, then the auto-deploy channel is unlikely to do this.
I think the result of this is that during the period when any auto-deploy
channels are being used, before the point
where the specifically configured channels are active, that some events
may not reach all their intended destination(s)
and some events may not be received by some SCA consumers listening on
those channels.
All of which might argue for a process of deploying the Domain channels
first, which kind of undermines the idea of
auto-deploying those channels.
Yours, Mike
|
|
Dr Mike Edwards
| Mail Point 146, Hursley
Park
|
|
STSM
| Winchester, Hants SO21
2JN
|
SCA & Services
Standards
| United Kingdom
|
Co-Chair OASIS SCA
Assembly TC
|
|
|
IBM Software Group
|
|
|
Phone:
| +44-1962 818014
|
|
|
Mobile:
| +44-7802-467431 (274097)
|
|
|
e-mail:
| mike_edwards@uk.ibm.com
|
|
|
|
|
OK, I'll take a stab at answering your question, although I'm just presenting
one alternative among many.
First, though, your wording interests me:
in the case where the channel concerned DOES
have configuration and it so happens that the channel is deployed to the
Domain some time after some of the
producers and consumers using the channel are deployed to the Domain.
What intrigues me is the notion that your use case allows you to assert
that something about the channel's configuration. Can that configuration
never change? If so, how would you deal with changing that? By
undeploying and redeploying it? Some other means?
I would apply whatever answer you have to that question to this one.
To wit:
Say that you do allow some form of runtime redeployment or modification.
So in this case the implementation MAY autodeploy the channel (RFC
2119 wording intentional). If someone chooses to redeploy the channel
with further configuration later, so be it. Use whatever form of
modification you were going to support in the case where the prior configuration
was not auto-deployed.
Say you don't allow modification. Then I'd say that your implementation
should either not allow for autodeployment, or that your implementation
should put up some reasonable bar to autodeployment.
Danny
On 2/8/2011 1:51 AM, Mike Edwards wrote:
Folks,
I'd appreciate it if someone could explain how things would work in the
case where the channel concerned DOES
have configuration and it so happens that the channel is deployed to the
Domain some time after some of the
producers and consumers using the channel are deployed to the Domain.
Yours, Mike
|
|
Dr Mike Edwards
| Mail Point 146, Hursley
Park
|
|
STSM
| Winchester, Hants SO21
2JN
|
SCA & Services
Standards
| United Kingdom
|
Co-Chair OASIS SCA
Assembly TC
|
|
|
IBM Software Group
|
|
|
Phone:
| +44-1962 818014
|
|
|
Mobile:
| +44-7802-467431 (274097)
|
|
|
e-mail:
| mike_edwards@uk.ibm.com
|
|
|
|
|
Danny and Eric's arguments have convinced me that auto-creation of
global channels make sense. It would certainly simplify config/deploy --
I won't have to create a separate composite that contains only the
channel name and then deploy it to the domain. Currently we do allow
this for the default channel ("//"). As Eric points out, my issue
wrt
error detection can be dealt with by tools (I can have a global option
or flag for the deployer). Given that we already allow this for the
default channel, and channels currently require no additional
configuration (one can have configuration, but is not required to),
autocreation would provide a consistent model and would make simple
deployment scenarios easier.
-Anish
--
On 2/7/2011 9:50 AM, Eric Johnson wrote:
> To be more explicit, and echo Danny's point, I think we have
four options:
>
> 1) Mandate that auto-creation of channels works
> 2) Mandate that auto-creation of channels never works
> 3) Identify specific situations where #1 or #2 are possible
> 4) Take no position (this may still imply changes to the spec, insofar
> as we highlight the point, while taking no sides)
>
> I raised the issue because #4, it seems to me, leaves the door open
for
> interoperability failures. ("I deployed X over here with no problems,
> but it doesn't work over there.")
>
> Insofar as I've recall the discussion of the concrete use cases for
> global domain channels (Oracle's F2F presentation), we explicitly
noted:
> no filters, no policies, and no bindings on said channels. Meaning,
> configuration optional, and it's just a name. If it is just a name,
why
> can't I auto-create?
>
> Anish notes that some people like the safety net of predefined names,
> and I agree that's useful. However, that can be addressed in a variety
> of ways that aren't nearly so heavy-handed as to simply deny the
> deployment. ("The domain contribution includes references to
global
> domain channel "foo" that doesn't yet exist. Continue/Cancel?).
>
> -Eric.
>
> On 2/7/11 9:30 AM, Danny van der Rijn wrote:
>> Yet all their configuration is optional?
>>
>> On 2/7/2011 3:39 AM, Mike Edwards wrote:
>>>
>>> Eric,
>>>
>>> My view is that global channels - indeed any channels - are
more than
>>> a name - they have configuration associated
>>> with them. A system which does not require them to be declared
makes
>>> it difficult to provide required configuration.
>>>
>>> Yours, Mike
>>> ------------------------------------------------------------------------
>>>
>>> Dr Mike Edwards
Mail Point 146, Hursley Park
>>> STSM
Winchester, Hants SO21 2JN
>>> SCA & Services Standards
United Kingdom
>>> Co-Chair OASIS SCA Assembly TC
>>> IBM Software Group
>>> Phone:
+44-1962 818014
>>> Mobile:
+44-7802-467431 (274097)
>>> e-mail:
mike_edwards@uk.ibm.com
>>>
>>>
>>>
>>>
>>>
>>> From:
Eric Johnson <eric@tibco.com>
>>> To:
Anish Karmarkar <Anish.Karmarkar@oracle.com>
>>> Cc:
sca-assembly@lists.oasis-open.org
>>> Date:
04/02/2011 17:14
>>> Subject:
Re: [sca-assembly] [Issue 253]: (1.2) Must a global domain
>>> channel be deployed before it can be used?
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>>
>>>
>>> On 2/4/11 1:37 AM, Anish Karmarkar wrote:
>>> > I don't see this being different than say requiring that
a variable be
>>> > declared before it is used.
>>> <eej>
>>> Which might be a perfect analogy.
>>>
>>> If the only point of a global channel is to establish a name,
then
>>> there's actually minimal value to declaring it before it is
used. Many
>>> dynamic languages work this way - Python & Ruby. In the
case of global
>>> domain channels, for many use cases, filters and bindings
don't make
>>> sense, so the channel just becomes a name. At which point,
declaration
>>> before use looks like ceremony over substance.
>>>
>>> </eej>
>>> >
>>> > -Anish
>>> > --
>>> >
>>> > On 2/1/2011 10:11 AM, Danny van der Rijn wrote:
>>> >> An interesting argument for tight coupling...
>>> >>
>>> >> On 2/1/2011 6:19 AM, Anish Karmarkar wrote:
>>> >>> I think this is a fine issue to raise, but I
don't quite support the
>>> >>> auto-creation proposal. The only global channel
that is
>>> >>> 'auto-deployed' or always exists is the default
channel.
>>> >>>
>>> >>> I would want the runtime to tell me if I referenced
a channel
>>> that has
>>> >>> not been deployed (unless it is the default channel,
which is the
>>> >>> exception). If I want a producer and consumer
(especially if they are
>>> >>> in different composites) to communicate over
a common channel, I
>>> would
>>> >>> want the system to catch typos. For example,
if the producer is
>>> >>> connected to the channel "//omg" and
the consumer is connected to
>>> >>> "//zomg", they would be deployed fine
but my application would not
>>> >>> work correctly.
>>> >>>
>>> >>> -Anish
>>> >>> --
>>> >>>
>>> >>> On 1/31/2011 10:19 AM, Eric Johnson wrote:
>>> >>>> Hi Peter,
>>> >>>>
>>> >>>> On 1/31/11 10:02 AM, Peter Niblett wrote:
>>> >>>>> Eric
>>> >>>>>
>>> >>>>> You said..
>>> >>>>>
>>> >>>>> Neither of the above indicate whether
or not the global domain
>>> >>>>> channel
>>> >>>>> can be used before it is referenced.
>>> >>>>
>>> >>>> Ah yes, the joys of a muddled brain on Monday
morning. You're
>>> >>>> correct -
>>> >>>> the question is whether or not the global
domain channel can be used
>>> >>>> before it is *created* via a contribution.
>>> >>>>
>>> >>>> Thanks for catching my circularity.
>>> >>>>
>>> >>>> -Eric.
>>> >>>>>
>>> >>>>> I'm not sure how you can "use"
a channel without referencing it (I
>>> >>>>> assume "reference" means "wire
to/from"), but I think the question
>>> >>>>> you
>>> >>>>> are asking is the one in the title -
"can you reference a channel
>>> >>>>> that
>>> >>>>> hasn't been defined to the SCA assembly?".
I think this is one
>>> place
>>> >>>>> where the current spec is clear.. you
can't reference a domain
>>> >>>>> channel
>>> >>>>> that hasn't been defined.
>>> >>>>>
>>> >>>>> So it looks as though your issue is to
say that we should
>>> change the
>>> >>>>> spec to say that it permits (in fact
requires) autocreation of
>>> domain
>>> >>>>> channels. Presumably these channels would
have to be created with
>>> >>>>> default attributes (though I know you
think they shouldn't have
>>> >>>>> attributes at all).
>>> >>>>>
>>> >>>>> Regards
>>> >>>>>
>>> >>>>> Peter Niblett
>>> >>>>> IBM Senior Technical Staff Member
>>> >>>>> Member of the IBM Academy of Technology
>>> >>>>> +44 1962 815055
>>> >>>>> +44 7825 657662 (mobile)
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>> From: Eric Johnson<eric@tibco.com>
>>> >>>>> To: OASIS SCA Assembly<sca-assembly@lists.oasis-open.org>
>>> >>>>> Date: 31/01/2011 17:19
>>> >>>>> Subject: [sca-assembly] NEW ISSUE: (1.2)
Must a global domain
>>> channel
>>> >>>>> be deployed before it can be used?
>>> >>>>>
>>> ------------------------------------------------------------------------
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>> Title: Must a global domain channel be
deployed before it can be
>>> >>>>> used?
>>> >>>>>
>>> >>>>> Target: Assembly 1.2 WD 03
>>> >>>>>
>>> >>>>> Description:
>>> >>>>>
>>> >>>>> Via the "@target" and "@source"
attributes defined on a consumer&
>>> >>>>> producer, the assembler can reference
global domain channels.
>>> >>>>>
>>> >>>>> In section 5.8, the presumed to be normative
text reads "SCA
>>> runtimes
>>> >>>>> MUST support the use of domain channels
[ASM????]." That is
>>> followed
>>> >>>>> by:
>>> >>>>>
>>> >>>>> "To create a Domain Channel, deploy
a composite containing a
>>> channel
>>> >>>>> directly to the SCA Domain (i.e., do
not use that composite as the
>>> >>>>> implementation of some component in the
Domain)."
>>> >>>>>
>>> >>>>> Neither of the above indicate whether
or not the global domain
>>> >>>>> channel
>>> >>>>> can be used before it is referenced.
>>> >>>>>
>>> >>>>> Proposal:
>>> >>>>>
>>> >>>>> General theme: do not require the global
domain channel to exist
>>> >>>>> before
>>> >>>>> it can be used.
>>> >>>>>
>>> >>>>> Specific text (needs refinement?):
>>> >>>>>
>>> >>>>> In section 5.8, Paragraph #2, append:
>>> >>>>>
>>> >>>>> When contributing artifacts to a domain
that contain references to
>>> >>>>> global domain channels that have not
been created, the SCA runtime
>>> >>>>> MUST
>>> >>>>> automatically create said global domain
channels, and cannot reject
>>> >>>>> such
>>> >>>>> contributions [ASM????].
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> ---------------------------------------------------------------------
>>> >>>>> To unsubscribe from this mail list, you
must leave the OASIS TC
>>> that
>>> >>>>> generates this mail. Follow this link
to all your TCs in OASIS at:
>>> >>>>>
>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> ------------------------------------------------------------------------
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>> /
>>> >>>>> /
>>> >>>>>
>>> >>>>> /Unless stated otherwise above:
>>> >>>>> IBM United Kingdom Limited - Registered
in England and Wales with
>>> >>>>> number 741598.
>>> >>>>> Registered office: PO Box 41, North Harbour,
Portsmouth, Hampshire
>>> >>>>> PO6
>>> >>>>> 3AU/
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>
>>> >>> ---------------------------------------------------------------------
>>> >>> To unsubscribe from this mail list, you must
leave the OASIS TC that
>>> >>> generates this mail. Follow this link to all
your TCs in OASIS at:
>>> >>>
>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>> >>
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe from this mail list, you must leave the
OASIS TC that
>>> > generates this mail. Follow this link to all your TCs
in OASIS at:
>>> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this mail list, you must leave the OASIS
TC that
>>> generates this mail. Follow this link to all your TCs in OASIS
at:
>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>>
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> /
>>> /
>>>
>>> /Unless stated otherwise above:
>>> IBM United Kingdom Limited - Registered in England and Wales
with
>>> number 741598.
>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
>>> PO6 3AU/
>>>
>>>
>>>
>>>
>>>
>>>
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]