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.
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.
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.
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.
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.
You either allow overriding or not - both are available.
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
