Re: [sca-assembly] Re: Comments on items from minutes of 2010-05-11

[Mike Edwards <mike_edwards@uk.ibm.com>]

Eric,

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

• I label them with @sources coming from a global channel, but then I've undermined composability
• Promote all the consumers with a unifying composite consumer.

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.

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

</mje>

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.

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


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?

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


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.

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

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.

<mje>
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.
</mje>

-Eric.

---

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