OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-assembly message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Looking for feedback on "injecting of channels"


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.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]