There is one issue wrt auto-deploy that has not been discussed in this
long thread that I wish to bring up: "garbage collection" of
auto-deployed channels.
Auto-deployed channels (obviously) don't require any explicit action to
deploy channels other than deployment of a producer/consumer that uses
that channel. In a dynamic SCA environment, the composites that
contained the producer/consumer that led to the auto-deploy of global
channels may be undeployed at some later time. This will leave the
domain-level channels that no one is using (and possible will never use)
intact. Since these channels were auto-deployed, it stands to reason
that they should be auto-undeployed (or garbage collected). Especially,
since the administrator does not have a composite to point to, to get
rid of the auto-deployed channel using the Assembly "10.7.2 remove from
Domain-Level Composite" operation.
-Anish
--
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.
>
> 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.
>
> 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.
>
>
> 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.
>
> 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.
>
>
> 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.
>
> 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.
>
>
> 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: .com_ <mailto:>
>
>
>
>
>
> From: Danny van der Rijn _<>_ <mailto:>
> To: Mike Edwards/UK/IBM@IBMGB
> Cc: -open.org_
> <mailto:>
> 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: .com_ <mailto:>
>
>
>
>
>
> From: Anish Karmarkar _<>_
> <mailto:>
> To: -open.org_
> <mailto:>
> 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: .com_ <mailto:>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> From: Eric Johnson _<>_ <mailto:>
> >>> To: Anish Karmarkar _<>_
> <mailto:>
> >>> Cc: -open.org_
> <mailto:>
> >>> 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_<>_ <mailto:>
> >>> >>>>> To: OASIS SCA Assembly_<>_
> <mailto:>
> >>> >>>>> 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/
>
>
>
>
>
>
