Re: [sca-assembly] Misadventures exploring "@coupledTo" for proposedresolution of ASSEMBLY-227

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

On 12/8/2010 8:10 AM, Mike Edwards wrote:
>
> Folks,
>
> I find it VERY hard to see how this "double headed beast" termed
> "prosumer" (or use whatever other term you find more congenial) is
> in any way simpler or avoiding of the problems laid at the door of
> either "groupID" or "coupledTo".
>
> The trouble with "prosumer" is that I think it ends up having to include
> all the features and capabilities of both a producer and a consumer,
> with the need for both @target and @source - and also allowing for

Why would you need both these attributes, since prosumer, when connected 
to a channel would connect both the underlying consumers and the producers?

> promotion (and in the worst case allowing for promotion to a
> prosumer, to a consumer & to a producer). AND the rule has to be that
> some combination of these things ensures that there is a "path"
> that connects the prosumer to itself via some channel.
>
> To avoid those problems, you end up having to place restrictions on what
> a prosumer can do - and any such restrictions are equally
> applicable to "groupID" or "coupledTo" (etc).

I agree; we would have to have restrictions regardless of whether it is 
a prosumer or a @groupID/@coupledTo.

>
>
> As for avoiding the notion of a producer explicitly naming a consumer -
> that IS the game we are in here. You can't hide it, no matter
> how you try. For sure, the producer and the consumer involved may be
> connected via some (as yet unspecified) channel, but the
> fact of them BEING connected to one another IS the point of this function.

I think there is a difference between having a producer explicitly name 
a consumer v. a producer just naming an abstract group that it is part 
of or having a prosumer construct point to the associated 
consumer/producers.

At some point, of course someone is going to know which 
producers/consumers are connected together. Right now we have a channel 
construct that provides that. If you knew all the channels in the domain 
then you can work through the hierarchy and figure out exactly which 
consumers are connected to which producers. But that still enables a 
disconnected model. OTOH, if the producer itself were to list the 
consumers it is connected to, there is coupling. For example, every time 
a new consumer enters the domain, I may have to update my producer.

>
>
> You want simplicity? Then don't have this "this producer must be
> connected to this consumer" type of function in the model at all.

Big +1
I thought we left simplicity far behind a while ago. But I would be 
happy to go back to it ;-)

-Anish
--

> Clearly an Assembler can achieve this function if they so wish - it's a
> piece of cake for the assembler. It's just that putting this metadata
> into the model in a way that it can be POLICED by the runtime (or by
> tooling) is what generates all this complexity. Leave it as
> descriptive metadata in the implementations/composites. Job done.
>
> 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: 	mike_edwards@uk.ibm.com 		
>
>
>
>
>
> From: 	Eric Johnson <eric@tibco.com>
> To: 	Anish Karmarkar <Anish.Karmarkar@oracle.com>
> Cc: 	sca-assembly@lists.oasis-open.org
> Date: 	07/12/2010 00:11
> Subject: 	Re: [sca-assembly] Misadventures exploring "@coupledTo" for
> proposed resolution of ASSEMBLY-227
>
>
> ------------------------------------------------------------------------
>
>
>
> Hi Anish,
>
> On 12/6/10 3:57 PM, Anish Karmarkar wrote:
>  > I think this is fine.
>  > Although, I do find the minimal change to CTs via Mike's proposal
>  > attractive. But certainly understand the complications that come with
>  > it wrt policy/intent and constrains like everything has to be promoted
>  > or connected.
>  >
>  > A minor difference, perhaps inconsequential at this stage is, wrt how
>  > I envisioned Mike's proposal to work:
>  > I didn't think of a @mustConnectTo or @coupledTo as the attribute we
>  > would use but an attribute such as @label or @groupID, which would be
>  > any arbitrary string. The @mustConnectTo or @coupledTo identified
>  > other consumers (or producers). I would rather the producers not point
>  > to consumers (or vice versa). Instead, the producers and consumers
>  > that are to be connected together would be identified with a common
>  > label/group id.
>
> In one of the later emails, Mike and I discussed the problems with a
> generic label, and I think we both agreed that a "groupID" kind of
> notion allowed for an extra axis of flexibility (promoting to two
> consumers on the composite, for example, but assigning the same group
> ID) that isn't required by the use case, and simply introduces an extra
> opportunity for confusion and mis-wiring. So we had agreed on
> @mustConnectTo in the email referenced below (00100).
>
> -Eric.
>
>  >
>  > -Anish
>  > --
>  >
>  >
>  > On 11/30/2010 1:47 PM, Eric Johnson wrote:
>  >> As per my action item, I've been trying to write up the approach that
>  >> I agreed to, the one that Mike suggested:
>  >>
>  >> http://lists.oasis-open.org/archives/sca-assembly/201011/msg00100.html
>  >>
>  >> Mike labeled this as "@mustConnectTo" in his proposal, but I thought it
>  >> more natural to call this "@coupledTo".
>  >>
>  >> Rather than spell out the changes I was making, let me instead describe
>  >> the corner I found myself in.
>  >>
>  >> Just about the time I wrote this:
>  >>
>  >> "The */coupled consumer and producer of a component/* is defined as a
>  >> consumer and producer from a component, where the componentType of the
>  >> component in question defines a consumer that has been @coupledTo a
>  >> producer from the same component."
>  >>
>  >> ... I realized I was in trouble.
>  >>
>  >> To make this notion work, when talking about composites, we have to make
>  >> normative statements to the effect of "whenever you promote a consumer
>  >> coupled to a producer, or vice-versa, the "coupled" consumer or producer
>  >> MUST also be promoted, and the resulting consumer and producer MUST be
>  >> reflected into the componentType of the composite as being coupled." To
>  >> that end, I wanted to define a notion of "coupled consumer and producer
>  >> of a component." That way, I could say more simply:
>  >>
>  >> "Either both parts of a coupled consumer and producer of a component
>  >> MUST be promoted and remain coupled, or neither is."
>  >>
>  >> We've also discussed that a "coupled consumer and producer of a
>  >> component" must also both be connected to a channel, if either of
>  >> them are.
>  >>
>  >> I can only begin to imagine the verbal knots we're going to get into
>  >> when we start applying policies, and have to introduce gems like "the
>  >> coupled consumer and producer of a component" must share the same policy
>  >> intents and policy sets.
>  >>
>  >> The difficulty here stems from a simple problem - producers and
>  >> consumers, so far at least, have independent existence, and now we want
>  >> to add text that couples them together tightly while still giving them
>  >> an independent identity.
>  >>
>  >> Having tried to write it up that way, I conclude it is far more natural
>  >> to reflect the notion of "prosumer"
>  >> (http://en.wiktionary.org/wiki/prosumer) (or conducer
>  >> http://en.wiktionary.org/wiki/conduce?) as Anish has stated, because:
>  >>
>  >> * That creates a thing with a single identity, to which specific
>  >> rules can be applied
>  >> * You don't have to create normative rules about how coupled
>  >> consumers and producers must be both promoted or neither is
>  >> promoted, and likewise about how they're both wired to a channel
>  >> or not. With a single prosumer, there's no question of a split, so
>  >> fewer normative constraints are required.
>  >> * The policy questions, as applied to a prosumer, are likely
>  >> different than those applied to consumers and producers
>  >> independently
>  >>
>  >> The beauty of the "coupledTo" approach is that it leaves the
>  >> componentType almost untouched - with just a single additional attribute
>  >> on either the consumer or producer. Unfortunately, I think adds huge
>  >> conceptual cost, and based on what I've seen from what I've tried to
>  >> write up, it obscures the underlying intended model.
>  >>
>  >> Having come to this conclusion, and considering that I want something
>  >> ready for our next call, I'm going to take a run at writing up the
>  >> "prosumer" approach starting Thursday or Friday of this week. That is,
>  >> unless I hear from others enough that convinces me I'm jumping the gun.
>  >>
>  >> -Eric.
>  >>
>  >
>  > ---------------------------------------------------------------------
>  > To unsubscribe from this mail list, you must leave the OASIS TC that
>  > generates this mail. Follow this link to all your TCs in OASIS at:
>  > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
>
>
>
>
> ------------------------------------------------------------------------
>
> /
> /
>
> /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/
>
>
>
>
>
>