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

[Danny van der Rijn <dannyv@tibco.com>]

I'm not sure if it's what you're getting at, but I see an analogy with 
SCA service's wireByImpl feature.  IIRC there is no standard way to 
transmit/receive the address, but there *is* a standard way for the 
unwired reference to specify that it will dictate at runtime what it 
would like to be wired to.

On 10/28/2010 4:41 PM, Anish Karmarkar wrote:
> 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
>
> ---------------------------------------------------------------------
> 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

S/MIME Cryptographic Signature