OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

sca-assembly message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [sca-assembly] A look at use-cases for composition with eventing, alternateapproaches to make them work better


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

> 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>


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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]