Folks,
Let me start my comments at the end
- with the "prosumer" concept.
I did not like that idea when it was
presented at the F2F and I still don't like it.
I find such a "two headed beast"
a strange concept and I don't like it because it
introduces something new into the model
which is both strange and also hard to
explain. I think it is unnecessary
and it also does not really capture the requirement
that is expressed.
Getting back to the requirement.
I think the concept is simple enough.
A component (whether it has a composite or an atomic
implementation) has 1 or more producer
and 1 or more consumer that must be connected
to the same channel so that any event
from any of the producers is enabled to reach any of
the consumers. However, the channel
itself is supplied by the composite which contains the
component, so its identity and other
connections (other producers, other consumers) are left
to the assembler to decide.
The further concept is the idea that
in the case of a composite implementation, the composite
itself could be configured to supply
a default channel, permitting the using composite NOT to
configure a channel.
I note that the second concept is strictly
optional - we can decide to toss it into the trash can and
this would not undermine the first concept.
I am minded to follow this second path, since the second
concept is merely causing confusion
at the present.
So let me concentrate on the first concept.
Note that I've presented it in perhaps a different way than
we have discussed in the past. I'm
deliberately moving away from the concept of an "injected channel"
since for the assembler there is no
real visibility of which events are produced and which are consumed
when using the "injected channel"
concept - and I don't think that is a good idea.
So, one idea is simply to express the
grouping of producers and consumers explicitly. This might take
the form of a "groupID" attribute
that can be applied to any producers and consumers. The implication
of "groupID" is simply that
all producers and/or consumers carrying the same "groupID" label
must be
connected to the same channel. If
they are not so connected, then the runtime is to regard the
composite as being in error and then
raise an error.
"groupID" would really only
apply to the consumers & producers of ONE component - ie if the same
"groupID" value appears on
2 or more component in 1 composite, that has no special significance.
Looking at things this way I note:
o The number of connections allowed
for any given consumer & producer is independent of any
groupID - all that a groupID says is
that there must be 1 channel common to all the consumers &
producers. If a consumer / producer
is limited to 1 channel, then that's it...if multiple connections are
allowed, then other connections can
be made without concern about the groupID, as long as 1
channel is common to all.
o it may be possible to permit more
than 1 groupID to be expressed for a given consumer / producer
enabling it to be part of multiple groupings
- this would assume that the given producer/consumer
can have multiple connections (the implication
is that there would have to be one connection for
each groupID present.... (PS I
am actually not very keen on this notion)
o Clearly any set of consumers / producers
with a given groupID could be decorated with policy
- in this case it is up to the implementation
creator to ensure that the combination of policy so expressed
actually makes sense.
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:
From:
Anish Karmarkar <>
To:
Date:
09/11/2010 06:31
Subject:
Re: [sca-assembly] Looking for feedback
on "injecting of channels"
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.
>
---------------------------------------------------------------------
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
