From: Mike Edwards
[mailto:mike_edwards@uk.ibm.com]
Sent: 10 November 2010 22:17
To: sca-assembly@lists.oasis-open.org
Subject: Re: [sca-assembly] Looking for feedback on "injecting of
channels"
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: mike_edwards@uk.ibm.com
From:
|
Anish
Karmarkar <Anish.Karmarkar@oracle.com>
|
To:
|
sca-assembly@lists.oasis-open.org
|
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