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

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

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