Re: [sca-assembly] [ASSEMBLY-249] Need some notion of "callback"address in conjunction with eventing

[Eric Johnson <eric@tibco.com>]

Hi Mike,

More good questions!

On 10/29/10 2:41 AM, Mike Edwards wrote:

OF653EFD69.717EC682-ON802577CB.00333DC6-802577CB.0034E56D@uk.ibm.com" type="cite">
Folks,

Some questions inline for clarification

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

Eric Johnson <eric@tibco.com> wrote on 29/10/2010 00:11:47:

> [sca-assembly] NEW ISSUE: Need some notion of "callback" address in
> conjunction with eventing
>
> Eric Johnson
>
> to:
>
> OASIS SCA Assembly
>
> 29/10/2010 00:16
>
> Title: Need some notion of "callback" address in conjunction with eventing
>
> Target: Assembly 1.2 WD 01
>
> Description:
> For some uses of eventing, the point of using an event driven system is
> to decouple a collection of asynchronous interactions.
>
> For example component A sends a message to component B, and A directs B
> to send a response to component C.

First question here is why this type of behaviour is not simply achieved in
SCA by using the composition itself?  That is, I can create a composition
of components A, B, C where a producer of A sends messages to a consumer
of B and a producer of B sends messages to a consumer of C.

Possibility #1 - we adopt something like the "autowire" notion I filed.  Explicit wiring would be counterproductive, if not impossible.

Possibility #2 - Components A, B, and C produce messages to send to D, in some situations D may send feedback information back to a reply-to address.  Since there are multiple components "producing" messages, the only way I see to simulate this in the current model would be to establish three different consumers on D, one for each of A, B, and C.  Of course, now we've actually coupled the shape of the solution, when a pub-sub environment should let me decouple them.

Possibility #3 - Components A, B, and C produce messages to send to all of D, E, and F.  If D, E, and F might choose to send back any sort of response to the "producing" components, we're back to a combinatorial wiring explosion, rather than simply modeling something like a JMS Topic as the binding for the channel.

OF653EFD69.717EC682-ON802577CB.00333DC6-802577CB.0034E56D@uk.ibm.com" type="cite">
Second question relates to the nature of the contract here.  How does
component A even know that component B will produce a "response" following
the receipt of some message from A? Decoupling actually implies this - that
component A can have no expectations of what component B will do when
receiving a given message.  It may be known to the assembler, but decoupling
implies that it is not known to the component writer...

This is definitely an important question.  I don't have a clear-cut answer.  My instinctual reaction suggests that this question should be at least partially out-of-scope to SCA itself.  Modeling semantics around complex interactions is beyond what SCA needs to do.  But we probably have to capture some simple ones.

One answer is actually quite simple.  The contract is partially implied by the message payload, and the presence of a "reply-to" address on the consumed message.  If the producer of the message doesn't send a "reply-to", that's OK, but if they do, then there's probably semantics related to the payload that deserves some kind of "response."

Another possible answer relates to a point that I think TIBCO (mostly me, really) have been remiss in following-up on.  There doesn't seem to be a particular reason why you couldn't actually use a WSDL like contract to describe some of these interactions - it is just that the communication is done via events, rather than via HTTP request/reply.

OF653EFD69.717EC682-ON802577CB.00333DC6-802577CB.0034E56D@uk.ibm.com" type="cite">
I get the feeling here that you're really trying to describe a service
style interaction based on asynchronous one-way messages.  No problem with
that, but why not use services & references for that?

#1) Nature of implied a-synchronicity
#2) "Reply" messages could be zero to many, as in: order-received, order-processed, order-packaged, order-shipped, order-in-transit, order-appears-to-have-arrived.  Further, it is possible that the "reply-to" destination is not a queue, but a topic, in JMS terms.

OF653EFD69.717EC682-ON802577CB.00333DC6-802577CB.0034E56D@uk.ibm.com" type="cite">
>
> JMS, for example, includes the JMSReplyTo property.  This allows for
> asynchronous communications, and allows for the sender to dictate where
> the response should go, eliminating any direct architectural coupling of
> the receiver with the sender.

Why should the sending component be the one to make these decisions rather
than the assembler who is composing some set of components into a coherent
application?

I think we're actually saying the same thing here, but I apparently expressed it poorly.  The declaration of the component in the composite, and the producer identified therein strikes me as the likely place to identify the "reply-to" consumer destination.  I think that's the file that the "assembler" you refer to creates/edits.  So I conclude (correctly?) that we agree.

OF653EFD69.717EC682-ON802577CB.00333DC6-802577CB.0034E56D@uk.ibm.com" type="cite">
>
> For the purposes of eventing in SCA, it is desirable on the "producer"
> side to send a message with a "reply" address pointing to some other
> consumer (or channel) on the component, or in the composite.
>
> Likewise, on the consumer side, it may be useful to tie that consumer to
> an "unwired" producer, where that producer never gets wired to anything
> but rather sends to the destination received by the consumer.

I simply don't understand the last sentence "sends to the destination
received by the consumer" - can you explain further please?


I also note in the description here that there seems to be an assumption
of direct connections from consumers to producers - or have I misunderstood?
The current model is essentially a pub/sub mediated kind of model, where the
channels act as multiplexers connecting a group of producers to some group
of consumers - there is no implication of a 1-to-1 connection.

I'm not against 1-to-1 connections, but it is necessary to make them part of
the model first.

I have not been assuming that there's any sort of one-to-one relationship.

What we may be missing is some sort of notion of whether an event is sent to a Topic or to a Queue.  There's not necessarily a single consumer, but there may be a single responder....

What you may be pointing out is that I lifted up a rock, and there are a bunch of bugs crawling around underneath.  Hmmm.

OF653EFD69.717EC682-ON802577CB.00333DC6-802577CB.0034E56D@uk.ibm.com" type="cite">
>
> Abstract proposal:
>
> In the case of a producer expecting a "reply", change the "producer" on
> a component so that it includes something like a "@replyTo" attribute.

This seems to make big assumptions about how the target component will
behave - the target may have 0 producers, 1 producer, multiple producers
and may produce 0, 1, or many events in response to a given message.
What should happen in the case of 0 events or of multiple events being
produced by the receiving component?

More sophisticated components may produce events only in response to
multiple events that may arrive from different producers.  How should
such events be treated?

Perhaps these are different questions, or perhaps they are different parts of the same one.  Maybe one of those many components delivering messages to a channel might include a "reply-to" address, and that "reply-to" might not be back to itself?

-Eric.

OF653EFD69.717EC682-ON802577CB.00333DC6-802577CB.0034E56D@uk.ibm.com" type="cite">
>
> In the case of a producer sending a "reply", change the producer to have
> a "inReplyTo" attribute that names a particular consumer on the same
> component (@target attribute & @replyTo attribute not allowed)
>
> -Eric.
>