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
<>
To:
Mike
Edwards/UK/IBM@IBMGB
Cc:
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>
<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
