[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-assembly] Looking for feedback on "injecting of channels"
I would like to understand this (the one about labeling the producers/consumers and requiring that ones with matching labels be connected to at least one common channel) further. If I got this right, the labels must be retained in any promotion and if one producer/consumer with label A is promoted all of the producer/consumers with the same label A must be promoted, unless they are already connected together via a channel (local or global). I think we should use a different name than 'GroupID', which can lead to incorrect impressions in the world of pub-sub. I do like the idea of moving away from thinking about this problem as an "injected channel", but I'm not a big fan of the second concept of a default channel provided by the composite. -Anish -- On 11/10/2010 2:16 PM, Mike Edwards wrote: > > Folks, > > Let me start my comments at the end - with the "prosumer" concept. > > I did not like that idea when it was presented at the F2F and I still > don't like it. > I find such a "two headed beast" a strange concept and I don't like it > because it > introduces something new into the model which is both strange and also > hard to > explain. I think it is unnecessary and it also does not really capture > the requirement > that is expressed. > > Getting back to the requirement. > > I think the concept is simple enough. A component (whether it has a > composite or an atomic > implementation) has 1 or more producer and 1 or more consumer that must > be connected > to the same channel so that any event from any of the producers is > enabled to reach any of > the consumers. However, the channel itself is supplied by the composite > which contains the > component, so its identity and other connections (other producers, other > consumers) are left > to the assembler to decide. > > The further concept is the idea that in the case of a composite > implementation, the composite > itself could be configured to supply a default channel, permitting the > using composite NOT to > configure a channel. > > I note that the second concept is strictly optional - we can decide to > toss it into the trash can and > this would not undermine the first concept. I am minded to follow this > second path, since the second > concept is merely causing confusion at the present. > > So let me concentrate on the first concept. Note that I've presented it > in perhaps a different way than > we have discussed in the past. I'm deliberately moving away from the > concept of an "injected channel" > since for the assembler there is no real visibility of which events are > produced and which are consumed > when using the "injected channel" concept - and I don't think that is a > good idea. > > So, one idea is simply to express the grouping of producers and > consumers explicitly. This might take > the form of a "groupID" attribute that can be applied to any producers > and consumers. The implication > of "groupID" is simply that all producers and/or consumers carrying the > same "groupID" label must be > connected to the same channel. If they are not so connected, then the > runtime is to regard the > composite as being in error and then raise an error. > > "groupID" would really only apply to the consumers & producers of ONE > component - ie if the same > "groupID" value appears on 2 or more component in 1 composite, that has > no special significance. > > Looking at things this way I note: > > o The number of connections allowed for any given consumer & producer is > independent of any > groupID - all that a groupID says is that there must be 1 channel common > to all the consumers & > producers. If a consumer / producer is limited to 1 channel, then that's > it...if multiple connections are > allowed, then other connections can be made without concern about the > groupID, as long as 1 > channel is common to all. > > o it may be possible to permit more than 1 groupID to be expressed for a > given consumer / producer > enabling it to be part of multiple groupings - this would assume that > the given producer/consumer > can have multiple connections (the implication is that there would have > to be one connection for > each groupID present.... (PS I am actually not very keen on this notion) > > o Clearly any set of consumers / producers with a given groupID could be > decorated with policy > - in this case it is up to the implementation creator to ensure that the > combination of policy so expressed > actually makes sense. > > > > > Yours, Mike. > > Strategist - Emerging Technologies, SCA & SDO. > Co Chair OASIS SCA Assembly TC. > IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain. > Phone & FAX: +44-1962-818014 Mobile: +44-7802-467431 > Email: mike_edwards@uk.ibm.com > > > From: Anish Karmarkar <Anish.Karmarkar@oracle.com> > To: sca-assembly@lists.oasis-open.org > Date: 09/11/2010 06:31 > Subject: Re: [sca-assembly] Looking for feedback on "injecting of channels" > > > ------------------------------------------------------------------------ > > > > Eric, > > I'm a bit confused about some of the things in the two proposals. For > example, in approach #1 I don't understand why it is necessary to have > the /composite/channel/@injectionPropertyName attribute in the > innerComposite. It seems that the channel name should be enough. IOW the > outerComposite channel can inject into myCoolComponent/myInnerChannel. I > also don't understand why the componentType would have the channel > details (such as filters etc) when injectionRequired is true. > > Quite possibly I have misunderstood the two approaches. But the above > are minor issues. I have two bigger issues with both approaches: > > 1) I don't like channels in component types. I don't know what that > means wrt CTs of atomic components. This also applies to properties that > are considered special/different. Whether the syntactic manifestation is > <property> or <MySpecialChannelSyntax> is serialization detail and have > the same effect on the model/tools. I can understand having a channel > property which can refer to composite properties (and whose values can > be set from above). That would allow me to inject configuration (but not > things like filters/intents). For a seed of this idea see > http://lists.oasis-open.org/archives/sca-assembly/201006/msg00071.html > > 2) Taking a step back. My understanding is that the requirement here is > not to define a channel in the inner composite but have a way to say > that a designated set of producers and consumers are connected together > via particular channel, but that you want to delegate the exact channel > identity to a higher-level composite. If that is correct then I believe > the ideas that we discussed at the f2f provide a better way to model > this: specify exactly which set of producers and consumers are connected > together and "promote" that set. No notion of channel is needed in this > case. We already allow for multiple producers to be promoted together > and multiple consumers to be promoted together. This would allow you to > mix producers and consumers while promoting. There were two syntactic > constructs discussed at the f2f for this -- > > a) <prosumer name="xs:NCName" promoteConsumers="list of xs:anyURI" > promoteProducers="list of xs:anyURI" .../> > > b) OR generalize the promotion syntax to: > <promote name="xs:NCName" consumers="list of xs:anyURI"? > producers="list of xs:anyURI"? /> > > Comments? > > -Anish > -- > > On 10/28/2010 5:48 PM, Eric Johnson wrote: > > I have action item 2010-09-22-8 to produce a new proposal for > > ASSEMBLY-227. > > > > During the F2F meeting, I believe Mike suggested exploring the option of > > treating "channel injection" as just a property of a special type or > > name. In that way, there would be no additional changes to the shape of > > the componentType, and further, that the componentType would not reflect > > aspects of design that were ostensibly specific to composites. > > > > I've been thinking about this further, and wondering if I get use some > > help to extract myself from the corner I've walked into. > > > > > > Approach #1) Injected channels as properties: > > > > > > Following this approach, on the derived componentType of a composite, I > > think I expect this: > > > > <componentType xmlns="http://docs.oasis-open.org/ns/opencsa/sca/200912"> > > > > <...> > > > > <property name="myChannel" element="*sca:channelInjection*"> > > * <sca:channelInjection injectionRequired="true" ...> > > <filters />? > > <eventType />? > > <binding />? > > <requires />* > > <policySetAttachment/>* > > </sca:channelInjection>* > > </property> > > > > < ...> > > > > </componentType> > > > > I don't think we can simplify sca:channelInjection (although we could > > give it a different/better name), because any outside composite must > > receive sufficient information to know what a valid channel injection > > might be. And it strikes me that any such validation will need to match > > up policy intents, policies, filters, and (perhaps) bindings. Since > > channel injection differs subtly from promotion, perhaps we can drop > > binding from the above, but the filters and policy related information > > seem essential to me. > > > > For the above to appear in the generated componentType, it must somehow > > be indicated by the composite. One straightforward way to do that is to > > change the definition of a channel in a composite to include the name of > > the property that defines the injection: > > > > <composite name="innerComposite" ...> > > > > <...> > > <channel name="myInnerChannel" > > *injectionPropertyName="myChannel"? > > injectionRequired="true"?* ...> > > <filters/>? > > <binding/>? > > <requires/>* > > <policySetAttachment/>* > > </channel> > > > > < ...> > > > > </composite> > > > > Do note that "@injectionRequired" reflects a detail we struggled with at > > the F2F. The outside composite is not obligated to inject a channel if > > this is "false", but the runtime is still obligated to create a channel > > for the inner composite. > > > > Now, in the composite containing the above "innerComposite", I actually > > need to be able to "inject" a channel I might define. How might that > look?: > > > > <composite name="outerComposite" ...> > > > > <...> > > <component name="myCoolComponent"> > > <implementation.composite name="innerComposite" /> > > </component> > > > > <channel name="myOuterChannel"*injectInto="myCoolComponent/myChannel > ..."* ...> > > < ...> > > </channel> > > <...> > > > > </composite> > > > > The above shows the link between the declaration of a channel, and how > > it would be injected into one or more composites that requested > > injection (notice the "..." - I meant to imply a list of target > injections). > > > > > > *Pros:* > > > > * As noted, no further additions to the componentType. > > > > *Cons:* > > > > * The "mustSupply" attribute on properties doesn't seem appropriate > > for the "sca:channelInjection" property, because the value of this > > property indicates whether or not a property value must be > > supplied, not whether or not a channel must be injected. > > * This "sca:channelInjection" property is a very odd property, > > because the property is actually binding on the composite that > > contains it. Further, even more strongly than @mustSupply="false", > > it is more like @mustNotSupply="true", but of course we don't have > > such an attribute. > > * In other places where' we've constrained how aspects of the > > outside component could "connect" to aspects of an inner > > component/composite, those aspects have always been explicitly > > modeled as part of the componentType, and this approach is > > inconsistent with that pattern, even if the "connection" is > > different from the other types of connections that we've defined. > > > > All of the above leads to: > > > > > > Approach #2) Injected channels as explicit part of componentType. > > > > Most of the above is very similar. The largest difference appears in how > > the channel injection is exposed as part of the componentType. > > Specifically, the componentType for "innerComposite" looks different: > > > > <componentType xmlns="http://docs.oasis-open.org/ns/opencsa/sca/200912"> > > > > <...> > > > > * <channelInjection name="myChannel" injectionRequired="true"> > > <filters />? > > <eventFilter />? > > <binding />? > > <requires />* > > <policySetAttachment/>* > > </channelInjection> > > * > > < ...> > > > > </componentType> > > > > The inner composite gets some subtle differences: > > > > <composite name="innerComposite" ...> > > > > <...> > > <channel name="myInnerChannel" > > *injectionName="myChannel"? > > injectionRequired="true"?* ...> > > <filters/>? > > <binding/>? > > <requires/>* > > <policySetAttachment/>* > > </channel> > > > > < ...> > > > > </composite> > > > > The outer composite looks exactly the same as it does under approach #1. > > > > *Pros:* > > > > * Does not overload the semantics of properties to impose new > > constraints on the outer composite. > > > > *Cons:* > > > > * Introduces a new aspect to the componentType, an aspect that > > appears to be specific to composites, or composite-like components > > > > Having gone through the above analysis, I definitely prefer Approach #2, > > with the specific addition to the componentType. That option feels to me > > like the semantics explicit. > > > > However, looking back at my original proposal (but without stripping out > > consumer & producer), it looks suspiciously like I've rearranged the > > deck chairs on the Titanic. The semantics around injection are > > definitely an important difference, but the syntax is so similar that > > I'm afraid this won't feel radically different to others. Thus my > > request for help and feedback. > > > > -Eric. > > > > --------------------------------------------------------------------- > 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/ > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]