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"
- From: Mike Edwards <mike_edwards@uk.ibm.com>
- To: Eric Johnson <eric@tibco.com>
- Date: Tue, 23 Nov 2010 09:13:09 +0000
Folks,
Comments inline as <mje>.../mje>
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 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:
- Producers and consumers that could otherwise be "hidden"
in the injected channel approach are now also available for independent
wiring
- No new element introduced into componentType
- No implication of anything actually being wired - although
when it is, there's a guarantee of being wired to the same thing
<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>
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>
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]