Danny,
Aside from any last minute testing issues for 1.1, most of the
F2F will be focussed on eventing.
Martin
From:
Danny van der Rijn [mailto:dannyv@tibco.com]
Sent: 27 August 2010 19:28
To: OASIS Assembly
Subject: Re: [sca-assembly] A look at use-cases for composition with
eventing, alternate approaches to make them work better
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: mike_edwards@uk.ibm.com
Danny van der Rijn <dannyv@tibco.com> 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