On 12/9/10 11:29 PM, Mike Edwards wrote:
Some revealing comments - some
On 12/8/10 8:10 AM, Mike Edwards wrote:
I find it VERY hard to see how this "double headed beast" termed
"prosumer" (or use whatever other term you find more congenial)
in any way simpler or avoiding of the problems laid at the door
"groupID" or "coupledTo".
I boil it down to the difference between negative and positive
I find it far more useful to search a list of positive
about what I MUST do with a "prosumer" rather than to search
a list of negative assertions about what I cannot do with a
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
If it is positive
that worries you, I am sure I can cast the requirements on
<eej>I probably should have pointed out as well that I found
myself wanting to have a label for the coupling of a producer and
consumer. Then, of course, I want to have normative statements
about that pairing. Once I've got normative statements about the
pairing, that begs the question as to why we're not simply
representing the pairing in the XML form.
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
(and in the worst case allowing
promotion to a
prosumer, to a consumer & to a producer).
That's nonsensical to me. I don't see any reason you ever allow
of a prosumer's characteristics once you've brought them
That is one of the
revealing comments on this issue so far.
What that says, in
is that linked producers/consumers CANNOT be used in ways that
<eej>To be precise, I said that I don't see any reason
for doing such a thing</eej>
I asked about this
F2F and didn't get a crisp answer. But the comment above
crisp. Let me paraphrase
how I read that
"When there is a
producer/consumer, the producer/consumer can only EVER be
such a way that the
always send every event from the producer to the consumer."
other words if I as the
Assembly happen to
to take the events from the producer and send them out to some
DOES NOT include
consumer, I can't do it. Even if I did have a separate
from the producer to
ensures that the required linking is satisfied.
<eej>All right, but you've identified a feature, not a
reason/scenario/use-case. Trying to identify the use case:
A component (CompA) has producer (ProdA) which is wired to multiple
channels (ChanA, ChanB). One of those channels (in order to solve
the use cases I've postulated) must be wired back to the coupled
The question, then is about the 2nd channel (ChanB). Why wire the
producer to it in the first place? I presume that some producers
(ProdB & ProdC) are sending messages to ChanB that aren't meant
to arrive at the coupled consumer (ConA) ? OK, but why not simply
have the downstream clients (ConB, ConC) consume both ChanA and
So it looks like that can't be the problem you're concerned about,
because within a single composite, I can still solve it with the
prosumer approach as we've discussed so far.
Perhaps then, you mean to wire the prosumer to a channel within the
composite, but then promote the producer half of it past the edge of
the composite? Can we explore this more? This involves at least
three levels of composite nesting to be interesting - the inner
composite (CompA) that defines a prosumer (or @coupledTo), a
containing composite that wants to promote the producer side of the
prosumer, and at least one final wrapping composite that will use
the events of that promoted producer. Can you draw a picture?
An odd realization: the "injected channels" approach solves just
this scenario, by way of letting producers and consumers explicitly
wire to the channel within the composite, or not, as they see fit,
and letting the use of that channel beyond the edge of the composite
happen at the whims of the subsequent assemblers. But then, I'm
confused, because you seem to have rejected the possibility of
solving this problem that way.
However, whether or not we pursue injected channels, I think the
analysis highlights a key point. To achieve your approach with
injected channels, obviously, I would promote ProdA to the edge of
the composite. To promote the channel to the edge of the composite
as well, I have to make an affirmative decision to *also* indicate
said channel at the edge of the composite.
Poking at the premise of your question, one question jumps into my
mind, why not simply require that the component CompA promote an
equivalent to ProdA uncoupled from the consumer ConA? I could ask
the same question with the injected channels approach - if, as a
component I chose to promote the channel, but not an independent
producer, is that OK?
Circling back, this seems to be one nugget of potential discussion
then - if I promote a coupled producer & consumer (via
@coupledTo, element prosumer, or injected channel - doesn't matter,
the problem is always the same), then are the events of the producer
separately available? (Note: I don't think this problem applies
equally to consumers, because a component implementation can already
decide whether or not to receive events outside of those coupled to
a producer by simply defining another consumer, so this is already
under the control of the component, rather than the assembler).
I can think of at least two ways I might extend the prosumer model
to encompass this requirement:
Care to comment on whether either seems better to you?
- Whenever a prosumer appears in a componentType, that implies
the existence of distinct producer with a related name
- Allow composite promotion of just the producer side of a
If my paraphrase
then I am now parting company from this whole notion of
is undermining the
to see Assemblers having at their fingertips. What's the
That seems somewhat draconian to throw the baby out with the
bath-water. Rather than reject the policy model outright, because
it might impose constraints on higher-level composites or unpleasant
complexity, we've started trying to figure out how that might work.
Same thing applies here - this notion of bottom-up constraints
matters, and we should have a discussion about what it means.
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.
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
results in wiring a *single* thing. How could the path you
to actually be broken?
This tends to
paraphrase above. The restriction implied is too great.
To avoid those problems, you end up having to place restrictions
a prosumer can do - and any such restrictions are equally
applicable to "groupID" or "coupledTo" (etc).
As for avoiding the notion of a producer explicitly naming a
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
be connected via some (as yet unspecified) channel, but the
fact of them BEING connected to one another IS the point of this
You want simplicity? Then don't have this "this producer must
be connected to this consumer" type of function in the model at
Clearly an Assembler can achieve this function if they so wish -
piece of cake for the assembler. It's just that putting this
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
I think the complexity of the current spec is somewhat
"One technique which enables component producers to send events
the composite and for component consumers to receive events from
the composite is to configure producers and/or consumers of
inside the composite to use domain channels – that is, channels
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
and receive events outside of the composite is to configure
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
a list of one or more target URIs in its @target attribute. The
endpoint declares the sources for the messages it receives
through a list
of one or more source URIs in its @source attribute. The form
these URIs include:
The above is simpler than the current
- The URI of a channel in the same composite as
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
to make a draft which uses the abstract notion of an event
anything other than the language. The concepts remain. A
ain't the same thing as a consumer.
Indeed, I argue
is an attempt to sweep complexity under the carpet. But the
is still showing. In fact, it is probably made worse.
<eej>As I've pointed out with the various diagrams that I've
drawn, and with various discussions of specific scenarios, when
trying to get to the bottom of the problems that arise when coupling
composition with eventing, we discover complexity. At the moment,
the 1.2 WD completely punts on addressing that complexity, by either
resorting to "use global channels", or creating hopelessly confused
Ignoring that complexity doesn't make it go away, it just pushes it
onto our customers, or into implementation-specific extensions that
solve it, but which won't be portable.
|| 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,
Unless stated otherwise
IBM United Kingdom Limited - Registered in England and Wales
Registered office: PO Box 41, North Harbour, Portsmouth,