Besides Eric's reply, I think that all I have left to say is that I
look forward to productive discussions at the F2F! I haven't seen
an agenda yet (which is probably not due to the lack of one being
published) but I hope we are devoting plenty of time (i.e. a day) to
this issue in particular, and plenty more time on eventing in
general.
On 8/26/2010 2: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.
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
S/MIME Cryptographic Signature
