Re: [sca-assembly] attempt at thread summary: looking for feedbackon "injecting of channels"

[Anish Karmarkar <Anish.Karmarkar@oracle.com>]

On 11/22/2010 5:52 PM, Eric Johnson wrote:
>   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
>
>
> 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.

I believe all three proposals would require some change to the 
componentType. In mine, we would have a new element called prosumer (or 
the generalized <promote> syntax in the CT.

> 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.
>

If a composite has a prosumer, the CT of that composite would contain a 
prosumer element. This is similar to how a promoted consumer/producer in 
a composite shows up as a producer/consumer in the CT of that composite.

If there is a prosumer element then any wiring of that prosumer wires 
all the lower-level consumers/producers that belong to the prosumer. If 
the intention is to allow for the lower-level consumers/producers to be 
wired separately (and independently) then they have to be promoted 
separately. I.e., you can promote the same consumer/producer as many 
times as you want; either independently or grouped together with others 
in a prosumer. This is similar to what we have now, where a consumer can 
be promoted as many times as you want either independently or together 
with other consumers.

> 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?
>

I hope the above clarifies it.

> 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.
>

As Mike noted this is already another issue.

> Did I miss any differences?
>

The biggest difference to me is that Mike's and my proposal result in a 
CT syntax that is applicable to both atomic components and components of 
type implementation.composite. AIUI, Eric's proposal would result in 
introducing the concept of 'injected channels' that apply only to CTs of 
composites but not to CTs of atomic components.

I should also note that in the abstract sense Mike's and my proposals 
aren't very different. Both provide a grouping mechanism. In Mike's 
proposal each individual producer/consumer points to the group(s) it 
belongs to, and in my proposal you create a grouping element 
(<prosumer>) that points to all of its members. Of course, this 
syntactic difference does result in differences in capabilities.

-Anish
--

> -Eric.
>
> [1] http://lists.oasis-open.org/archives/sca-assembly/201011/msg00038.html