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