Anish,
Some comments inline...
Yours, Mike
Dr Mike Edwards
Mail Point 146, Hursley
Park
Technical Strategist
Winchester, Hants SO21
2JN
SCA & Services
Standards
United Kingdom
Co-Chair OASIS SCA
Assembly TC
IBM Software Group
Phone:
+44-1962 818014
Mobile:
+44-7802-467431 (274097)
e-mail:
From:
Anish Karmarkar <>
To:
Date:
16/11/2010 08:15
Subject:
Re: [sca-assembly] Looking for feedback
on "injecting of channels"
I would like to understand this (the one about labeling
the
producers/consumers and requiring that ones with matching labels be
connected to at least one common channel) further. If I got this right,
the labels must be retained in any promotion and if one
producer/consumer with label A is promoted all of the producer/consumers
with the same label A must be promoted, unless they are already
connected together via a channel (local or global).
<mje>
Yes, that would be the
idea - either directly connect the relevant producers and consumers
with a channel, or else
promote them to composite producers/consumers which all
share the same ID - either
of these would be viewed as "satisfying" the grouping
requirement.
</mje>
I think we should use a different name than 'GroupID', which can lead to
incorrect impressions in the world of pub-sub.
<mje>
No problem with that -
can you think of a suitable name? I'm not the greatest inventor of
names, for sure....
</mje>
I do like the idea of moving away from thinking about this problem as an
"injected channel", but I'm not a big fan of the second concept
of a
default channel provided by the composite.
<mje>
I agree - I'm for dropping
that concept. I'd need convincing that such an idea really
adds much at all - other
than confusion, that is
</mje>
-Anish
--
On 11/10/2010 2:16 PM, Mike Edwards wrote:
>
> 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/
>
>
>
>
>
>
---------------------------------------------------------------------
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
