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] Re: Comments on items from minutes of 2010-05-11


Comments inline as <mje>...</mje>

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

From: Eric Johnson <eric@tibco.com>
To: sca-assembly@lists.oasis-open.org
Date: 14/05/2010 20:35
Subject: [sca-assembly] Re: Comments on items from minutes of 2010-05-11

Some comments related to ASSEMBLY-227:

<Mike Edwards>I take the view that composability requires that producers and consumers are treated as all independent

My response: I'm not clear that they are all always independent.  Scenario: three consumers on three different components, all brought together in the same composite, and the messages that they listen to come from "outside" of the composite - so they need to be "promoted" in some sense, across the composite boundary.  What if it is my design intent as the creator of the composite that these consumers are all listening to the same "channel".  How do I make that happen under the current proposal?

I think I have two ways
In either case, though it is worth noting that in both of the above scenarios, I'm not treating these consumer as independent.  By design they are supposed to be listening to the same channel.

I think that you have correctly identified the 2 options.

I also note that for both options, it is the ASSEMBLER who gets to choose that the 3 consumers all get their events from
the same source.  So as far as I am concerned, the Consumers ARE all independent, but the composition imposes on
them one and only one source for events.  This is as it should be - Assembler gets to decide.

I agree that setting @source to a global channel undermines composability.  Direct access to global channels does have
that as a consequence.

It strikes me as odd that not all consumers are independent of each other, and likewise producers are not necessarily independent of each other,  but that we want to make the distinction that producers and consumers are always independent.  That's a distinction that feels like a carry over from a point-to-point world.

You need to carefully spell out what you mean by "independent" here.

I think that each component consumer IS independent of any other component consumer.
Each consumer receives its messages from whatever source(s) are configured.  Each component
will process messages independently of the other compoennts. If the Assembler
happens to configure identical sources for 2 or more consumers, then they will all get the same
sequence of messages (assuming no filtering for a moment), but that was a deliberate decision
of the Assembler.

Surely this is modelled very simply in today's pub/sub world - multiple consumers can listen to
events on the same Topic for example.  So there is nothing new here - merely a convenient way of
modelling this in SCA

It seems like a perfectly reasonable use-case to me that I would define multiple consumers within a composite that all want to be promoted, and at the same time define a producer that will be sending messages to those consumers, and I want that producer promoted.  How do I indicate that intent, and do so in a composable way?

Depends on your intention here.

If you promote *anything* you are giving the power to the user of the composite (the Assembler of a higher level
composite) the ability to configure the promoted elements in any way that they choose.

If this isn't what you want, then don't promote stuff.

So in your scenario, you can indeed have a consumer and a producer on components in a composite.  You can
promote the consumer and promote the producer.  You can also have the producer send messages directly to the
consumer through a channel that is entirely within the composite containing the components.

This would ensure that messages from the producer are always sent to the consumer, but this undermines some
aspect of composability - in that an Assembler using that composite could never prevent the messages from flowing
from that producer to that consumer - all that the Assembler using that composite in a higher component could do
is to
a) send the producer messages to additional target consumers

b) send messages from other producers to the consumer

How you lay out the composite depends on what kind of composability you want to have - some choices within the
composite will limit what the Assembler using that composite can do.. But giving more choice to the Assembler
may mean that the intentions of the lower level composition get changed.  You can't have it both ways.

At the moment, if I attempt to solve this by using @source and @target, I've forced that particular channel to be local, and the consumers in this case would have to be promoted.  And I also have to promote the producer.  But now this has a different meaning than I've intended, because the messages being produced on the channel are not going beyond the edge of the composite, and the promotions of the consumers and producers are independent.

Well, not quite - it is possible that all messages produced on the "private" channel are also promoted and so ALL
"go beyond the edge of the composite".

The promotions of consumers and producers are indeed independent, since that is what promotion means.  Why is
this a problem?

MikeE: What does a promoted channel look like and how would you do it in Java?

This question confused me at first.  I'm not quite sure I understand this question - it seems to be two questions.  What does a promoted channel look like - I've put that in my proposal.  To summarize, my proposal simply moves the existing notions of producer and consumer under a single umbrella channel element.  I'm not suggesting that consumers and producers automatically appear under the same channel, only that they can.

As to how you do it in Java, the answer is - it hasn't changed, really.  There is, perhaps, an additive piece.  All I'm suggesting is a different expression of the producer(s) and consumer(s) as part of the component type.  If the producers and consumers within a Java component are not all completely independent, then we probably need to add an annotation that ties producers and consumers together with a shared label.  That shared label would then signal that the consumer and producer should appear under the same channel definition in the component type.  If combining producers and consumers on a channel is not interesting to the Java developer, then they wouldn't have to specify anything different than they would otherwise have to do with the current proposal, and the net effect would be a "channel" declared in the component type for each of the producers and consumers.

The question was deliberately provoking and awkward - because it points up a problem with your proposal.

In my opinion, a composite is an implementation just like a Java POJO is an implementation.  I see no difference
from an SCA perspective - and I could potentially replace one with the other in my composite application.

So I was trying to get at how possibly I could have a Java component with a consumer and a producer that are
in some way tied to each other.

I don't see how this can be done for a Java component.  I don't see the use for it either.

As a result, I have the same problem for a composite - the promoted consumers and producers are always
simply independent in my model and there is no notion of them not being independent.  I don't see the need
to tie any consumer to any producer.  Neither do I see a need to promote a channel.  I can't see a use case
that makes such function useful or interesting.


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]