Re: [sca-assembly] Looking for feedback on "injecting of channels"

[Anish Karmarkar <Anish.Karmarkar@oracle.com>]

On 11/9/2010 5:12 PM, Eric Johnson wrote:
> 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.

Are these constrains independent, or are they additive? If additive, 
which direction -- outer composite channel constrains get added to the 
inner composite channel, or the other direction, or both directions.

>
>>
>> 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.
>

I like to think of prosumers as just another kind of promotion. I 
suppose they exhibit the same model as your proposal, but only for the 
case where injectionRequired="true" (unless I misunderstood the proposal).

> 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.

Indeed. I thought I had pointed that out as well at the f2f.
But it does address the usecase where I want to have the inner composite 
channel go to the "same place" as the outer composite channel, by 
setting the configuration/property of those channel to point to the same 
thing. As a trivial example, I can have a property that tells me which 
JMS topic to use (along with connection info) and set the property value 
to be the same for both channels. But I would indeed agree that from a 
modeling perspective it does not provide you with the view that they are 
indeed the same thing.

>
>>
>> 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.

I came to a different conclusion on this one at the f2f ;-)
I thought the cardinality of channels was thought to be a separate and 
orthogonal issue. (Didn't we open such an issue already?)

>
> 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.

I'm not convinced of this model, yet.

>
>> 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?
>

+1

-Anish
--

> -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
>
> ---------------------------------------------------------------------
> 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