[ASSEMBLY-249] Need some notion of "callback" address in conjunction witheventing

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

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.

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

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?

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

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

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

> 
> 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.
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS
at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>

---

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