Hi Anish,
On 11/30/10 12:45 AM, Anish Karmarkar wrote:
4CF4B9A8.40506@oracle.com" type="cite">
<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.
...
</eej>
I would like to understand how your proposal would work for
the atomic component. IIRC, your proposal provided some sort
of 'default' channel if none is injected. This would require
an atomic component to provide a channel implementation.
Well, no. At this point, we're arguing over which component of a
system does what. Is it the SCA "framework" that creates the
channel, or a "component". When a composite declares a channel in
the model, I simply don't think of that as the composite creating a
channel at runtime. I rather think of that as the composite
modeling for the runtime that a channel is required, and must be
manufactured according to requirements. That doesn't mean that the
implementation of implementation.composite actually knows how to
manufacture channel instances - at most it knows how to tell the
runtime what it needs.
So I see an "atomic" component as possibly declaring that it needs a
channel injected, and then the runtime injects it. Does it really
make sense, at this level of abstraction, to worry about which part
of the runtime is responsible for creating the "injected channel",
so long as we agree that it *isn't* the business logic?
-Eric.
4CF4B9A8.40506@oracle.com" type="cite">
-Anish
--
On 11/23/2010 11:34 AM, Eric Johnson wrote:
4CEC1734.5060309@tibco.com" type="cite">
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:
OFFE950B21.5B13EF69-ON802577E4.0031AFB1-802577E4.003233CD@uk.ibm.com"
type="cite">
Folks,
Comments inline as <mje>.../mje>
Yours, Mike
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>
OFFE950B21.5B13EF69-ON802577E4.0031AFB1-802577E4.003233CD@uk.ibm.com"
type="cite">
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>
OFFE950B21.5B13EF69-ON802577E4.0031AFB1-802577E4.003233CD@uk.ibm.com"
type="cite"> 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
|