Re: [sca-assembly] Looking for feedback on "injecting of channels"

[Mike Edwards <mike_edwards@uk.ibm.com>]

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:	mike_edwards@uk.ibm.com

From:	Anish Karmarkar <Anish.Karmarkar@oracle.com>
To:	sca-assembly@lists.oasis-open.org
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: 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/
>
>
>
>
>
>

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