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. "
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. 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 ...
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.
Redeployment is something that we must describe in general for all
of SCA. 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
S/MIME Cryptographic Signature
