Next in thread →
Next in month →
Re: [sca-assembly] attempt at thread summary: looking for feedbackon "injecting of channels"
Hi Mike,
The picture came through on my email at least. It also appears
here:
http://lists.oasis-open.org/archives/sca-assembly/201011/msg00100.html
(in case anyone else didn't get it).
I like both the picture for #1, and your pattern of solution for #2
(I'm going to thing a little about the name of the attribute).
Since it is still my action item to produce a proposal for 227, I'm
more than happy to see if I can take what you've got here, and turn
it into a complete proposal in the doc. At least I'll see where the
issues come up. Or, you can take a run at it if you wish, since I
won't get to it until Monday.
I may not finish for next Tuesday's call, but hopefully I'll dig in
far enough to note some questions.
-Eric.
On 11/24/10 8:15 AM, Mike Edwards wrote:
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:
From:
Eric Johnson
<>
To:
Mike
Edwards/UK/IBM@IBMGB
Cc:
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 <>
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
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
Next in thread →
Next in month →