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

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:  

Eric Johnson <> 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