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,alternate approaches to make them work better

Hi Mike,

Perhaps we're getting somewhere.

On 08/26/2010 02:56 AM, Mike Edwards wrote:
OF8FCEC917.ED6FEB59-ON8025778B.00351660-8025778B.003671A1@uk.ibm.com" type="cite">

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.

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.

OF8FCEC917.ED6FEB59-ON8025778B.00351660-8025778B.003671A1@uk.ibm.com" type="cite">
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).

OF8FCEC917.ED6FEB59-ON8025778B.00351660-8025778B.003671A1@uk.ibm.com" type="cite">

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.

OF8FCEC917.ED6FEB59-ON8025778B.00351660-8025778B.003671A1@uk.ibm.com" type="cite"> 

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.

OF8FCEC917.ED6FEB59-ON8025778B.00351660-8025778B.003671A1@uk.ibm.com" type="cite">
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.

OF8FCEC917.ED6FEB59-ON8025778B.00351660-8025778B.003671A1@uk.ibm.com" type="cite">
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.


OF8FCEC917.ED6FEB59-ON8025778B.00351660-8025778B.003671A1@uk.ibm.com" type="cite">

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]