Hi Mike,
Perhaps we're getting somewhere.
On 08/26/2010 02:56 AM, Mike Edwards wrote:
Folks,
One comment inline....
Yours, Mike.
Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great
Britain.
Phone & FAX: +44-1962-818014 Mobile: +44-7802-467431
Email:
Danny van der Rijn <>
wrote
on 25/08/2010 21:40:59:
> [image removed]
>
> Re: [sca-assembly] A look at use-cases for composition
with
> eventing, alternate approaches to make them work better
>
> Danny van der Rijn
>
> to:
>
> OASIS Assembly
>
> 25/08/2010 21:45
<snip>
>
> Of all your options, the last one is the cleanest, but it
does raise
> a question, and that is whether the composite implements
a
> component, or a channel - or both. As you have drawn it,
it
looks
> like it is a combination of both, and I am worried that
complicates
> things by muddling the concepts.
>
> <vdR>
> In the last two options, I think Eric is trying to show
that the
> *coupling* of the producer and consumer as part of the
> componentType. In this last example that you're
highlighting,
since
> the consumer and producer are shown separated, there's
certainly the
> possibility of ambiguity in what this might mean in the
graphical
> form. If you overlay the semantics that the runtime
merely treats
> them as referring to the same thing, then this is just
constraining/
> delegating to the runtime to connect producers and
consumers, in the
> same way that the runtime connects services and
references.
> </vdR>
<snip>
It is this notion of coupling of a producer and
a
consumer of *ONE COMPONENT* that
I find simply baffling. In my way of thinking,
there is no meaning to this and I
don't think it has a place in the model.
The point of my raising the issue was to address this question in
the context of composability. So I'm not interested in primarily in
a situation in which a component is implemented by Java, BPEL, or
C++, but when a component is implemented by a composite (although I
think Danny's use case is a good one).
Within the scope of some higher-level composite, what are the
chances, when setting values for @source and @target for components
however arbitrarily nested within other composites implementing
components, that no two of those @source and @target attributes
would ever refer to the same global domain channel. Or alternately,
that the developer used specific concrete bindings that referred to
the same concrete transport destination. Especially for the logging
example that Danny gave, it is actually extremely likely.
Let me give you possible normative statements that I'm fairly
certain you will disagree with:
Within the scope of a composite, there MUST NOT be a pairwise
match of @source and @target values.
Further, if components within that composite are implemented
by a composite, then across all of those components, and the
composite itself, there MUST NOT be any pairwise match of
@source and @target values that refer to the same global domain
channel. (I could probably state this one better, but hopefully
you get the idea)
Within the scope of a composite, these MUST NOT be bindings on
any possible pair of producer and consumer that refer to the
same transport resource.
Or, here's a fun one: @source and @target can be used to refer
to global domain channels, but MUST NOT be used in that manner
as part of a composite for a component of implementation type
implementation.composite.
If you don't like these normative statements, then we've left the
door open to the use cases I'm trying to explore. The question,
then, is whether we acknowledge the possibility of trying to solve
these cases without resorting to global domain channels
(composability).
Although you disagree with the use case, I've had occasion to talk
with one of our most experienced field deployment people, and as
near as I can tell, we did come to agreement that coupling producer
and consumer in this way is quite useful.
If you have a component that is implemented by
a composite
and that composite
contains multiple components, with producers
and consumers,
with some of those promoted
to the composite level, then the implication in
SCA
terms is very clear and very simple.
Those producers and consumers are made
available for
the assembler at the higher
level to connect as they wish. The only
restriction
is based on the set of events
declared for each consumer/producer and any
security
metadata that might be attached
to them.
OK. Seems a reasonable start. I think I'm just asking that we be
able to impose one small *additional* constraint to benefit some use
cases. (Although I'll grant that that one additional constraint
might radically change how you think about the model).
I don't think there is any use in trying to say
-
"Dear Assembler, this consumer and this
producer are made available for you to connect
up,
but you *must* ensure that events from
the producer are sent to the consumer".
Let's assume for a moment that at the lowest
level
composite there is a producer emitting
logging events and that there is a consumer set
up
to handle logging events. This would
be apparent from the event types declared on
them.
The simplest choice for the creator of
that composite is to promote the producer and
consumer
and let the user of the composite
decide how to connect them - they have to
decide where
to send the producer's events and
where to source the producer's events.
Agree that this is a possible scenario. But now, if I have built
that "innermost" component/composite, and I need to guarantee that
messages from the producer go to the consumer, I have two choices:
Connect the two directly, so that the producer sends events to
the consumer, as well as promoting the producer
Somehow communicate the intent to the higher level composite
that will encapsulate my composite as a component that the two
are tied.
Just the one producer and one consumer is mostly a trivial case.
That's why I came up with the example diagrams that I produced. The
pictures didn't really get interesting or complicated until I got
past two or three of each of producer and consumer. I've tried to
explore all sorts of different means of composability, in all sorts
of composability scenarios, with different degrees of nesting, and
different relationships between producers and consumers. Some
scenarios work just fine under the current draft, such as the easy
scenario shown on page one. Most of the other cases that I came up
with got really ugly. Perhaps my favorite use case is #3, shown on
page 8 of channel scenarios5.pdf. Although I cannot articulate
exactly what the real-world scenario would be, I suspect that this
case is a reasonable one, or at least is close to what might
happen. And the current WD makes it quite difficult to do.
It may well be that there is simply one channel
at
the higher level which deals with logging
events. In this case the simple thing happens
- events are sent from the producer to the
consumer. However, the assembler at the higher
level *has other choices*. One example is
that they can decide to send all the events to
one
channel and source events from another
one. And perhaps the connection between those
channels is actually some other component
that is actively processing the events - with
the
result that the event sets in the two
channels are not the same. This may be the
desire
of the assembler - and it must be what
composability means.
I agree that you've identified one possible scenario. Specifically
when it comes to policy, we're perfectly happy for a component to
put constraints on how a composite might promote a service or a
reference - those policy intents must still be honored. For that
matter, when a composite promotes a service, it is constrained to
exposing a compatible subset of what the service defined. This just
seems like another case where a component, might, if it chooses, put
additional constraints on how it might be used in a composite that
contains it.
If the designer of the lower level composite
wants
to *guarantee* that events from the producer
always reach the consumer, then a connection is
made
between them *in the lower level composite*
and it can't be overridden.
Again, my diagrams attempt to explore this notion in the context of
the existing WD, and in the context of my proposal, and other
possible options that I could think of. In the end, I think the
pictures speak for themselves.
You either allow overriding or not - both are
available.
And I'm (apparently not too successfully!?) pointing out that there
is actually a third option, that of letting the componentType convey
an additional constraint on how the producer and consumer should be
treated, if the component developer so chooses.
-Eric.
Yours, Mike.
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
