OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-assembly message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [sca-assembly] attempt at thread summary: looking for feedback on "injectingof channels"



Eric,

As always, the problem of inline comments is that they get out of hand very fast indeed.  So I'll simply extract the bits that I want
to comment on, to try to keep things clear

1. "In any event, as a reminder, going back to my "channel scenarios 5" PDF (http://lists.oasis-open.org/archives/sca-assembly/201008/msg00006.html),
I think I show something of how this might be diagrammed as per the picture on the top of page 4."

If I have got the right diagram, I don't think that the picture on top of page 4 looks right at all.
In my way of thinking, what you get is a top level composite with a channel which also contains a component
built from a composite, where one producer and one consumer of that composite are marked as having the same
"groupID" - and thus the top level composite is obliged to connect both the producer and the consumer to that channel.

If you have multiple nesting levels, one additional twist that I see is that IF a composite does not connect the producer
and consumer to the same channel, then both producer and consumer MUST be promoted to the composite level AND
the composite producer/consumer must be marked with the same "groupID"

I can draw this if you like, but it may not arrive with this email email





red circle == producer/consumer is marked with "groupID"

 2. "I don't see the value of allowing the same group ID on more than one "consumer" and "producer" declared in the composite"

If that is the case, then you can reduce the concept to the following:

add a simple label onto the producer element that contains the name of the consumer element to which it must be linked.

- you don't need to label the consumer with anything
- you're not needing to create some separate set of names (since you simply use a consumer name...)

something like:  @mustConnectTo="consumerX"



Yours, Mike

Dr Mike Edwards  Mail Point 146, Hursley Park
STSM  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: Eric Johnson <eric@tibco.com>
To: Mike Edwards/UK/IBM@IBMGB
Cc: sca-assembly@lists.oasis-open.org
Date: 23/11/2010 19:39
Subject: Re: [sca-assembly] attempt at thread summary: looking for feedback on "injecting of channels"





HI Mike,

Well, that does seem like progress.  Hopefully Anish can chime in with what he meant to end up in the componentType, and I can try to pull together a proposal from that.

More thoughts below:

On 11/23/10 1:13 AM, Mike Edwards wrote:


Folks,


Comments inline as
<mje>.../mje>

Yours, Mike


From: Eric Johnson <eric@tibco.com>
To: Mike Edwards/UK/IBM@IBMGB
Cc: sca-assembly@lists.oasis-open.org
Date: 23/11/2010 01:57
Subject: Re: [sca-assembly] attempt at thread summary: looking for feedback on "injecting of channels"






Trying to pull the threads together on this discussion.  I'm going to run with the point I made in one of my emails - just what, exactly, are we exposing in the componentType when attempting to resolve 227?

Three proposed approaches, and their effect:

Eric: "Injected" channels, wherein componentType exposes a new element for the injectedChannel.  This effectively exposes the filters, events, policies of the consumers and producers connected to the "injected" channel.

Mike: Continue to promote the consumers and producers, and then tie them together with a notion of "groupID".  In effect, this exposes the filters, events, policies of the consumers and producers and groups them for channel wiring purposes.

Anish: "Prosumer" which promotes the a combination of consumers and producers.

Writ-large, I think all of the above are introducing the exact same set of information into the componentType, with subtle variations in intended meaning.

Mike's proposal compares to mine in that where I would not promote the consumers/producers tied to the injected channel, but then indicate some of the key metadata about the consumers/producers wired to the channel-to-be-injected, Mike's proposal would promote them, and then tie them together with groupID.  Key differences here:

<mje>

In my opinion, the idea of marking producers and consumers in the componentType as belonging to the same "group" has the advantage of working

for any kind of implementation - atomic or composite.  I am not sure how to describe an "injected channel" when dealing with an atomic implementation.


</mje>

<eej>We could, of course, also make my proposal work for either atomic or composite components.  Based on what I've said, to satisfy the same requirements, my proposal - at least in some scenarios - pushes less data into the componentType for a component, but otherwise, it is exactly the same set of data expressed in a different syntax.

So I don't understand your point about not being sure how to describe the meaning of an "injected channel" - it is the exact same notion - a bunch of producers and consumers grouped together under an identity.  How you want to think about that is (mostly) a matter of interpretation.

In any event, as a reminder, going back to my "channel scenarios 5" PDF (
http://lists.oasis-open.org/archives/sca-assembly/201008/msg00006.html), I think I show something of how this might be diagrammed as per the picture on the top of page 4.

I don't see the value of allowing the same group ID on more than one "consumer" and "producer" declared in the composite - those elements already have the ability to roll up any number of consumers/producers from the contained components.  So one aspect of the groupID notion that concerns me is that it adds an additional axis of grouping that's just confusing.  I mention this, only because the diagram I mention above doesn't quite capture the notion that multiple consumers could be promoted to different promotion points and yet share a single group ID.  So for further discussion should note this distinction between the picture I referenced, and this aspect of the group ID.

</eej>


Anish's proposal differs from mine in terminology, and in intent.  Where I would have the injected channel *always* provided, Anish's proposal would defer the wiring question to the composer of the containing composite.  Unclear to me - at least from Anish's latest email [1], is whether or not he sees the same information being in the componentType that apparently Mike and I do.  That is, Anish's email documents the change to the composite, not how it reflects in the componentType.  It is unclear from Anish's proposal (at least to me) whether or not the promoted producers & consumers are available for separate wiring.

There's also a different pattern reflected in Anish and Mike's proposals - where the "injected channels" approach defines a 1-to-M mapping between a channel defined by a surrounding composite, and the producers/consumers wired to it, the proposals from Mike and Anish instead define a M-to-N relationship between the channels of the surrounding composite, and the producers/consumers of the contained component.

Steps forward:
1) Anish, can you provide a description of what you think ends up in the componentType in your prosumer model?

2) If we pursue an approach like Anish and Mike's does anyone have any feedback on a policy intent notion like "must-wire", so that an inner composite can force that its consumers/producers are wired up?  This approach would then be a functional superset of my injected channels approach.

<mje>

The issue of cardinality, dealt with in ASSEMBLY-251, addresses the question of "must wire" - in that issue a cardinality of 1..1 implies - "this producer/consumer MUST be connected to one and ONLY one channel"


The reason to raise that issue and to separate it from 227 is that cardinality seems independent of the notion of requiring some set of producers and consumers to use the SAME channel.

</mje>



<eej> Thanks for pointing that out.  I had overlooked ASSEMBLY-251 for some reason. </eej>


Did I miss any differences?

-Eric.

[1]
http://lists.oasis-open.org/archives/sca-assembly/201011/msg00038.html






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












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]