On 12/9/2010 11:29 PM, Mike Edwards wrote:
Eric,
Some revealing comments - some
responses
inline....
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:
From:
Eric Johnson
<>
To:
Mike
Edwards/UK/IBM@IBMGB
Cc:
Date:
08/12/2010 23:09
Subject:
Re: [sca-assembly]
Misadventures exploring
"@coupledTo" for proposed resolution of ASSEMBLY-227
Hi Mike,
On 12/8/10 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".
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
a constraint.
<mje>
If it is positive
vs negative
that worries you, I am sure I can cast the requirements on
consumers /
producers
using positive
assertions
</mje>
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 promotion
Yes.
(and in the worst case allowing
for
promotion to a
prosumer, to a consumer & to a producer).
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
together.
<mje>
That is one of the
most
revealing comments on this issue so far.
What that says, in
my terms,
is that linked producers/consumers CANNOT be used in ways that
are
standard for
non-linked
ones.
This is very similar to what we do for consumers (or producers) when
promoted together.
Everybody outside the composite that promoted the consumers (or
producers) have no clue that there is essentially a fan-out (or a
fan-in) going in. For example, if consumer A and B get promoted
together as consumer C, a higher level composite when it connects C,
necessarily connects A and B. Of course, I'm allowed to promote just
A and just B as well.
I
asked about this at the
F2F and didn't get a crisp answer. But the comment above
seems very
crisp. Let me paraphrase
how I read that
comment:
"When there is a
linked
producer/consumer, the producer/consumer can only EVER be
connected in
such a way that the
channel(s)
connecting them
always send every event from the producer to the consumer."
In
other words if I as the
Assembly happen to
want
to take the events from the producer and send them out to some
group of
consumers which
DOES NOT include
the linked
consumer, I can't do it. Even if I did have a separate
connection
from the producer to
the linked
consumer which
ensures that the required linking is satisfied.
If my paraphrase
is correct,
then I am now parting company from this whole notion of
linking. This
is undermining the
capabilities that
I want
to see Assemblers having at their fingertips. What's the
point of
that??
</mje>
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
composite
results in wiring a *single* thing. How could the path you
refer
to actually be broken?
<mje>
This tends to
confirm my
paraphrase above. The restriction implied is too great.
</mje>
Why? If this kind of splitting was desired, the underlying composite
should promote the producer(s)/consumer(s) separately as well. No?
To go back to my diagram from the f2f, once you create a
hermaphrodite (prosumer), you can't go back to splitting the two
sexes.
-Anish
--
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).
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.
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 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.
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
Domain level."
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 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
//channelName
The above is simpler than the current
text.
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
endpoint.
<mje>
This isn't
simplifying
anything other than the language. The concepts remain. A
producer
ain't the same thing as a consumer.
Indeed, I argue
that it
is an attempt to sweep complexity under the carpet. But the
big bulge
is still showing. In fact, it is probably made worse.
</mje>
-Eric
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:
From:
Eric
Johnson <>
To:
Anish Karmarkar <>
Cc:
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
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
