[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 channelbe deployed before it can be used?
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: mike_edwards@uk.ibm.com > > > > > > From: Danny van der Rijn <dannyv@tibco.com> > To: Mike Edwards/UK/IBM@IBMGB > Cc: OASIS Assembly <sca-assembly@lists.oasis-open.org> > 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: _mike_edwards@uk.ibm.com_ <mailto:mike_edwards@uk.ibm.com> > > > > > > From: Danny van der Rijn _<dannyv@tibco.com>_ <mailto:dannyv@tibco.com> > To: Mike Edwards/UK/IBM@IBMGB > Cc: _sca-assembly@lists.oasis-open.org_ > <mailto:sca-assembly@lists.oasis-open.org> > 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: _mike_edwards@uk.ibm.com_ <mailto:mike_edwards@uk.ibm.com> > > > > > > From: Anish Karmarkar _<Anish.Karmarkar@oracle.com>_ > <mailto:Anish.Karmarkar@oracle.com> > To: _sca-assembly@lists.oasis-open.org_ > <mailto:sca-assembly@lists.oasis-open.org> > 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: _mike_edwards@uk.ibm.com_ <mailto:mike_edwards@uk.ibm.com> > >>> > >>> > >>> > >>> > >>> > >>> From: Eric Johnson _<eric@tibco.com>_ <mailto:eric@tibco.com> > >>> To: Anish Karmarkar _<Anish.Karmarkar@oracle.com>_ > <mailto:Anish.Karmarkar@oracle.com> > >>> Cc: _sca-assembly@lists.oasis-open.org_ > <mailto: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>_ <mailto:eric@tibco.com> > >>> >>>>> To: OASIS SCA Assembly_<sca-assembly@lists.oasis-open.org>_ > <mailto: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/ > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]