OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

sca-assembly message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [sca-assembly] attempt at thread summary: looking for feedbackon "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

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.

Did I miss any differences?


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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]