Re: [sca-assembly] NEW ISSUE: Need some notion of "callback" addressin conjunction with eventing

[Anish Karmarkar <Anish.Karmarkar@oracle.com>]

I think this could be done by using event message metadata (some kind of 
reply-to header). I don't think there is anything in the current model 
that prevents this (although there is no effort to standardize event 
metadata). Are you suggesting standardization of metadata with this issue?
On the part about consumer tied to an unwired producer, the consumer is 
allowed to react to an event (or not) in any way it deems appropriate 
(application logic) including invoking a one-way operation on a service 
offered by the same component that produced the original event, OR 
raising its own event (the original event may have enough information 
about the channel binding and how to get to it). Why do we need this 
tie-up? I can see this would be interesting if there was some use of 
policy/binding injection on the responding producer. We have disallowed 
bindings on producer/consumers and wrt policy -- I know we haven't 
really decided on policy matching -- but this could complicate, the 
already complicated, eventing policy issue further.

-Anish
--

On 10/28/2010 4:11 PM, Eric Johnson wrote:
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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