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: [ASSEMBLY-249] Need some notion of "callback" address in conjunction witheventing


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

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

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]