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


On 6/25/2010 3:49 AM, Mike Edwards wrote:
>
> Anish,
>
> OK, now I've finally had some time to devote to your email.
>
> OK, I see your idea as far as the lower-level composite is concerned.
> But how does it look from the higher level composite
> and the configuration of the component that uses the lower level
> composite as its implementation?

It shows up as a property in the CT of the lower-level composite. No 
different than any other property of a CT. The idea is that when you set 
the value of a component property, you have to know exactly what the 
property represents, in this case the assembler that assembles the 
higher-level composite has to know that this is a channel property.

>
> I presume that, as in my example, the higher level component effectively
> wants to reference some Channel in the higher
> level composite as the value of the property - "ChannelW" in my last
> snippet. So, how would this be done?

No. The whole idea is that the channel is still a local channel. The 
only thing that the higher-level is allowed to do is to set the 
properties/configuration of the local channel. It cannot connect 
consumers/producers to it. If the higher-level composite can refer to 
lower-level channels then it is no longer a local channel. This is why I 
think the two proposals address different requirements.

>
> Can I assume:
>
> a) the TYPE of the property would be something like
> "sca:ChannelReference" (something we'd define)
>

What I'm proposing is that the type of the property can be anything that 
suits your needs. It is no different than any other component property.

> b) the way of setting the value of the property at the higher level
> would need some new infrastructure, say like adding a new
> @channelReference attribute to <property/>, which would simply contain
> the name of a Channel
>

I think you are trying to solve a different use case, which this 
proprosal does not satisfy. This proposal intends to keep local channel 
local. It just allows to say that I don't know, for example, which JMS 
topic this channel will be bound to when deployed, I'm going to delegate 
this to the higher-level.

> eg:
>
> <component name="HigherComponent">
> <implementation.composite name="CompositeX"/>
> <property name="foo" channelReference="ChannelW"/>
> <consumer name="Bar_Handling" source="ChannelZ"/>
> </component>
>
> (this is a kind of a hybrid from your example and mine combined!!)
>
> The problem with this approach is again that it means that it is not
> simple to replace the composite implementation with some
> atomic one... I don't see that a Java implementation would ever have a
> property of the ChannelReference type - after all, what would it
> do with it?
>
> That means that I still prefer my idea of having the channel setting
> being an implementation-dependent feature unique to
> implementation.composite
> which is not reflected in the componentType. I'm open to persuasion
> though....
>
>
> 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
>
>
> From: 	Anish Karmarkar <Anish.Karmarkar@oracle.com>
> To: 	sca-assembly@lists.oasis-open.org
> Date: 	22/06/2010 16:21
> Subject: 	Re: [sca-assembly] ASSEMBLY-227: Promotion of consumers and
> producers undermines 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/
>  >
>  >
>  >
>  >
>  >
>  >
>
> ---------------------------------------------------------------------
> 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
>
>
>
>
>
>
> ------------------------------------------------------------------------
>
> /
> /
>
> /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]