[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"
Hi Anish, A run at a response: On 11/8/10 10:24 PM, Anish Karmarkar wrote: > 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 debated with myself on just this point. At the time I was writing this up, my instinct came down on the side of indirection, because I could define a single injection point for multiple channels. Maybe that's a very odd thing to do, but I figured there might be more value from the level of indirection, and not exposing the internal details of the composite. I concede that I might have over-designed. > I also don't understand why the componentType would have the channel > details (such as filters etc) when injectionRequired is true. As I see it, the assembler of an outer composite might find this information valuable. Suppose they have defined four channels defined in their composite - which one are they supposed to inject into the contained composite? The one that matches the appropriate constraints, of course. It now falls to us to figure out is which constraints matter. I think the filters, events, and policies all matter. > > 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 If you don't like the manifestation of channels in component types, then I don't think your notion of "prosumer" below is actually fundamentally any different in this regard. As near as I can tell, in the componentType, it nets out to almost exactly the same information set. As to your idea from that email back in June, it isn't quite the same. You're controlling aspects of the definition of the channel via properties, rather than the identity of the channel. It doesn't net out to covering the same use cases. > > 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. I think our understanding from the F2F had a subtle twist, which is where the notion of "injection" comes in. Specifically, we want to make sure that, for the inner composite, producers and consumers are *always* wired. What's left to the containing composite, and the assembler thereof, is whether that assembler wants to dictate to the inner composite which channel to use, so that it can also watch off some events, or whether it just wants to leave it alone. In either case, our conclusion at the F2f was that the inner composite needed to be properly wired together. To that end, we settled on the notion of "injection". Either the containing composite will inject the channel identity, or the runtime will do so. At least as terminology goes, the "injection" notion more closely maps to what I think this means/how it should work, so thanks to Mike for identifying this term at the F2f. > 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? The above syntax is fine for how it manifests in a composite. I come back to the point I made about the componentType above - if you're going to start wiring this information in a containing composite, the componentType needs to reflect more information, and then your "prosumer", as manifested in the componentType, starts looking a lot like an injected channel. This suggests a useful avenue of discussion. Exactly what do we expect to manifest in a componentType? How much of a contract are we defining here? Can it work without exposing eventTypes, filters, and policies? -Eric. > > -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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]