On 12/8/10 8:10 AM, Mike Edwards wrote:
I find it VERY hard to see how
"double headed beast" termed "prosumer" (or use whatever
other term you find more congenial) is
in any way simpler or avoiding of
problems laid at the door of either "groupID" or "coupledTo".
I boil it down to the difference between negative and positive
assertions. I find it far more useful to search a list of positive
assertions about what I MUST do with a "prosumer" rather than to
search a list of negative assertions about what I cannot do with a
producer and consumer that are "coupled". With the positive case, I
can simply search the spec for references to "prosumer". In the
negative case, I must read everything to make sure I haven't missed
The trouble with "prosumer"
is that I think it ends up having to include all the features
of both a producer and a consumer,
with the need for both @target
- and also allowing for promotion
type="cite"> (and in the worst
case allowing for promotion
prosumer, to a consumer & to
That's nonsensical to me. I don't see any reason you ever allow for
splitting of a prosumer's characteristics once you've brought them
AND the rule has to be that some combination of these things
that there is a "path"
that connects the prosumer to
via some channel.
Since the prosumer has a single identity, defining it at the edge of
a composite, and then wiring that to a channel in the containing
composite results in wiring a *single* thing. How could the path
you refer to actually be broken?
To avoid those problems, you end
having to place restrictions on what a prosumer can do - and any
applicable to "groupID" or
As for avoiding the notion of a
explicitly naming a consumer - that IS the game we are in here.
can't hide it, no matter
how you try. For sure, the
and the consumer involved may be connected via some (as yet
channel, but the
fact of them BEING connected to
another IS the point of this function.
You want simplicity? Then don't
have this "this producer must be connected to this consumer"
type of function in the model at all.
Clearly an Assembler can achieve
function if they so wish - it's a piece of cake for the
just that putting this metadata
into the model in a way that it
be POLICED by the runtime (or by tooling) is what generates all
Leave it as
descriptive metadata in the
I think the complexity of the current spec is somewhat
manufactured. Take this:
"One technique which enables component producers to send events
outside the composite and for component consumers to receive events
from outside the composite is to configure producers and/or
consumers of components inside the composite to use domain channels
– that is, channels at the Domain level."
Suppose we define "event endpoint" as encompassing "producers" and
"consumers". I can then rewrite the above as:
"One technique which enables event endpoints of components to send
and receive events outside of the composite is to configure those
event endpoints to use domain channels - that is, channels at the
Now, notice that if I define "event endpoint" as encompassing
"producers", "consumers", and "prosumers", the the above statement
stays exactly the same.
Consider the following revision:
An event endpoint declares where the messages it produces are sent
through a list of one or more target URIs in its @target attribute.
The event endpoint declares the sources for the messages it receives
through a list of one or more source URIs in its @source attribute.
The form of these URIs include:
The above is simpler than the current text.
- The URI of a channel in the same composite as the producer, in
the form channelName
- The URI of of a channel at the Domain level in the form
To bear the above assertions out, I'm currently going through and
trying to make a draft which uses the abstract notion of an event
|| Mail Point
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
> 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
> I envisioned Mike's proposal to work:
> I didn't think of a @mustConnectTo or @coupledTo as the
> would use but an attribute such as @label or @groupID,
> any arbitrary string. The @mustConnectTo or @coupledTo
> other consumers (or producers). I would rather the
producers not point
> to consumers (or vice versa). Instead, the producers and
> 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
generic label, and I think we both agreed that a "groupID"
notion allowed for an extra axis of flexibility (promoting to
consumers on the composite, for example, but assigning the
ID) that isn't required by the use case, and simply introduces
opportunity for confusion and mis-wiring. So we had agreed on
@mustConnectTo in the email referenced below (00100).
> On 11/30/2010 1:47 PM, Eric Johnson wrote:
>> As per my action item, I've been trying to write up
>> I agreed to, the one that Mike suggested:
>> Mike labeled this as "@mustConnectTo" in his
but I thought it
>> more natural to call this "@coupledTo".
>> Rather than spell out the changes I was making, let
>> the corner I found myself in.
>> Just about the time I wrote this:
>> "The */coupled consumer and producer of a component/*
defined as a
>> consumer and producer from a component, where the
>> component in question defines a consumer that has
>> producer from the same component."
>> ... I realized I was in trouble.
>> To make this notion work, when talking about
composites, we have
>> normative statements to the effect of "whenever you
>> coupled to a producer, or vice-versa, the "coupled"
consumer or producer
>> MUST also be promoted, and the resulting consumer and
>> reflected into the componentType of the composite as
>> that end, I wanted to define a notion of "coupled
>> of a component." That way, I could say more simply:
>> "Either both parts of a coupled consumer and producer
>> MUST be promoted and remain coupled, or neither is."
>> We've also discussed that a "coupled consumer and
>> component" must also both be connected to a channel,
>> them are.
>> I can only begin to imagine the verbal knots we're
going to get
>> when we start applying policies, and have to
introduce gems like
>> coupled consumer and producer of a component" must
the same policy
>> intents and policy sets.
>> The difficulty here stems from a simple problem -
>> consumers, so far at least, have independent
existence, and now
>> to add text that couples them together tightly while
>> an independent identity.
>> Having tried to write it up that way, I conclude it
is far more
>> to reflect the notion of "prosumer"
as Anish has stated, because:
>> * That creates a thing with a single identity, to
>> rules can be applied
>> * You don't have to create normative rules about
>> 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,
>> different than those applied to consumers
>> The beauty of the "coupledTo" approach is that it
>> componentType almost untouched - with just a single
>> on either the consumer or producer. Unfortunately, I
>> conceptual cost, and based on what I've seen from
what I've tried
>> 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
>> "prosumer" approach starting Thursday or Friday of
week. That is,
>> unless I hear from others enough that convinces me
> To unsubscribe from this mail list, you must leave the
OASIS TC that
> generates this mail. Follow this link to all your TCs in
To unsubscribe from this mail list, you must leave the OASIS
generates this mail. Follow this link to all your TCs in
Unless stated otherwise
IBM United Kingdom Limited - Registered in England and Wales
Registered office: PO Box 41, North Harbour, Portsmouth,