<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.
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.
-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:
From:
Danny van der Rijn <>
To:
Mike
Edwards/UK/IBM@IBMGB
Cc:
OASIS Assembly <>
Date:
11/02/2011 19:33
Subject:
Re: [sca-assembly]
[Issue 253]: (1.2) Must a global domain channel be
deployed before it can be used?
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:
From:
Danny van
der Rijn <>
To:
Mike
Edwards/UK/IBM@IBMGB
Cc:
OASIS Assembly <>
Date:
09/02/2011 17:34
Subject:
Re: [sca-assembly]
[Issue 253]: (1.2) Must a global domain channel be
deployed before it can be used?
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:
From:
Danny van
der Rijn <>
To:
Mike
Edwards/UK/IBM@IBMGB
Cc:
Date:
08/02/2011 22:02
Subject:
Re: [sca-assembly]
[Issue 253]: (1.2) Must a global domain channel be
deployed before it can be used?
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:
From:
Anish
Karmarkar <>
To:
Date:
08/02/2011 09:15
Subject:
Re: [sca-assembly]
[Issue 253]: (1.2) Must a global domain channel be
deployed before it can be used?
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:
>>>
>>>
>>>
>>>
>>>
>>> From: Eric Johnson <>
>>> To: Anish Karmarkar <>
>>> Cc:
>>> 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<>
>>> >>>>> To: OASIS SCA Assembly<>
>>> >>>>> 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
