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: Re: [sca-assembly] ASSEMBLY-227: Promotion of consumers and producersundermines composability


This is an interesting idea.

I, too, do not like the non-uniformity. We were thinking about Scott's 
comment from last week too and came up with using properties to do this:

An example of this would be:

<composite name=.....>

    <property name="foo" type="xxx">
       <value/>
    </property>

    <channel name="bar">
       <property name="xxx" source="$foo"/>
    </component>

</composite>

What this means is that the channels have properties, they can be 
"promoted" and higher-level composites can set properties of local 
channels (if promoted). Which, is what I thought was what Scott was 
getting at and what the usecase was -- you want to connect the local 
producers/consumers, but you do not know how the channel is going to 
manifest in the implementation. For example, the property might point to 
a particular JMS destination.

Comments?

-Anish
--

On 6/22/2010 7:07 AM, Mike Edwards wrote:
>
> Folks,
>
> In last weeks' TC meeting, Scott said something that finally enabled me
> to understand the meaning of "promoting a channel" which several previous
> weeks of discussion had not got through to me. Perhaps I was just being
> dense (most likely) or the light had not fallen on the right part of the
> concept.
>
> So, if I have it right now, then "promotion of a channel" from a
> composite is perhaps better described as "the channel has a settable
> channel resource",
> in the same way that a composite can have a settable property value that
> is used by one or more of its containing components. We're not really
> promoting the channel here, rather we're trying to say
>
> "this composite uses a channel as part of its configuration, but the
> exact channel that is used can be set by the assembler when the
> composite is used
> as the implementation of some higher level component"
>
> So today:
>
> <composite name=.....>
>
> <property name="foo" type="xxx">
> <value/>
> </property>
>
> <component name="bar">
> <implementation ..../>
> <property name="xxx" source="$foo"/>
> </component>
>
> </composite>
>
> This ensures that the composite has a property "foo" in its
> componentType, which is thus settable when the composite is used as the
> implementation of
> some component. However, there is a value declared and so if the using
> component does not set a value for that property, the composite will use
> that
> value as a default.
>
> OK, so let's now turn to Event Processing and Channels:
>
> <composite name="CompositeX"...>
>
> <consumer name="Bar_Handling"
> promotes="Component2/FooHandling"/>
>
> <component name="Component1">
> <implementation.java class="org.example.Component1Impl"/>
> <producer name="Foo_Events" target="ChannelA"/>
> </component>
>
> <component name="Component2">
> <implementation.java class="org.example.Component3Impl"/>
> <consumer name="Foo_Handling" source="ChannelA"/>
> </component>
>
>
> <channel name="ChannelA" externallySettable="true"/>
>
> </composite>
>
> Here is a simple composite with 2 components and a channel. I've added a
> @externallySettable attribute to the channel - what I intend this to
> mean is
> something along the lines of "this channel can be configured by the
> component that uses this composite as an implementation". The using
> component
> might look something like this:
>
> <component name="HigherComponent">
> <implementation.composite name="CompositeX"/>
> <consumer name="Bar_Handling" source="ChannelZ"/>
> <configureChannel channelName="ChannelA" useChannel="ChannelW"/>
> </component>
>
> ...
>
> <channel name="ChannelW"/>
> ...
> <channel name="ChannelZ"/>
>
>
> So, "HigherComponent" does its usual configuration of the <consumer/>
> exposed by the composite CompositeX, but now in addition it does some
> configuration of the externallySettable channel that the composite also
> exposes - setting that channel to "ChannelW", which is declared in the
> higher
> composite. In this case "ChannelA" in the lower composite is simply
> overridden and replaced by "ChannelW".
>
>
>
> One big problem that I have with this is that it makes
> implementation.composite not quite the same as implementation.xxx eg
> implementation.java,
> since these other types will not have replaceable channels of this type.
> I don't like non-uniformity of the componentType and lack of replaceability
> of one implementation with another.
>
> Perhaps this calls for an alternative approach which makes it plain that
> these things are unique to composites, by placing the configuration into
> the
> <implementation.composite/> element, like this:
>
> <component name="HigherComponent">
> <implementation.composite name="CompositeX">
> <configureChannel channelName="ChannelA" useChannel="ChannelW"/>
> <implementation.composite>
> <consumer name="Bar_Handling" source="ChannelZ"/>
> </component>
>
>
> Well, enough ramblings of the confused for now - what do you think of
> this direction?
>
>
> 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
>
>
> ------------------------------------------------------------------------
>
> /
> /
>
> /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]