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:
<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.
Comments inline as <mje>.../mje>
Trying to pull the threads together on this
I'm going to run with the point I made in one of my emails -
what, exactly, are we exposing in the componentType when
Three proposed approaches, and their effect:
Eric: "Injected" channels, wherein componentType exposes a new
element for the injectedChannel. This effectively exposes the
events, policies of the consumers and producers connected to the
Mike: Continue to promote the consumers and producers, and then
together with a notion of "groupID". In effect, this exposes
the filters, events, policies of the consumers and producers and
them for channel wiring purposes.
Anish: "Prosumer" which promotes the a combination of consumers
Writ-large, I think all of the above are introducing the exact
of information into the componentType, with subtle variations in
Mike's proposal compares to mine in that where I would not
consumers/producers tied to the injected channel, but then
of the key metadata about the consumers/producers wired to the
Mike's proposal would promote them, and then tie them together
Key differences here:
- Producers and consumers that could otherwise
in the injected channel approach are now also available for
- 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
In my opinion, the
of marking producers and consumers in the componentType as
the same "group" has the advantage of working
for any kind of
- atomic or composite. I am not sure how to describe an
channel" when dealing with an atomic implementation.
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
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.
Anish's proposal differs from mine in terminology, and in
I would have the injected channel *always* provided, Anish's
defer the wiring question to the composer of the containing
Unclear to me - at least from Anish's latest email , is
or not he sees the same information being in the componentType
Mike and I do. That is, Anish's email documents the change to
composite, not how it reflects in the componentType. It is
from Anish's proposal (at least to me) whether or not the
& consumers are available for separate wiring.
There's also a different pattern reflected in Anish and Mike's
- where the "injected channels" approach defines a 1-to-M
between a channel defined by a surrounding composite, and the
wired to it, the proposals from Mike and Anish instead define a
relationship between the channels of the surrounding composite,
producers/consumers of the contained component.
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
feedback on a policy intent notion like "must-wire", so that
an inner composite can force that its consumers/producers are
This approach would then be a functional superset of my
The issue of
dealt with in ASSEMBLY-251, addresses the question of "must
- in that issue a cardinality of 1..1 implies - "this
MUST be connected to one and ONLY one channel"
The reason to
issue and to separate it from 227 is that cardinality seems
of the notion of requiring some set of producers and consumers
to use the
<eej> Thanks for pointing that out. I had
overlooked ASSEMBLY-251 for some reason. </eej>
Did I miss any differences?
Unless stated otherwise
IBM United Kingdom Limited - Registered in England and Wales
Registered office: PO Box 41, North Harbour, Portsmouth,