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

[Eric Johnson <eric@tibco.com>]

Hi Martin,

On 10/29/10 7:02 AM, Martin Chapman wrote:
> Doesn't seem like something that needs addressing at  the SCA level. If any producer can include a "reply-to" then all consumer components need to be prepared to do something with it i.e. it's implicit that there may be production of "response" events.

My trite response is that if you simply disregard this case, then anyone 
who wants to do anything with JMS that naturally maps onto the use of 
the JMSReplyTo message header, either cannot do it with SCA eventing, or 
can only do it with vendor specific extensions.  Both possibilities seem 
wrong to me.  JMS has been around a lot longer than SCA eventing, and if 
we cannot model appropriately around one of its key features.....

For a more substantive response, I can refer back to the responses I 
sent Mike - there are a number of what I think are reasonable scenarios 
where trying to wire this in the current model doesn't work.

Your point does make me wonder whether a consumer might flag that as 
part of an eventFilter that it may disallow reply-to information, or 
perhaps simply ignore it.

I raised the issue because I think we've overlooked something important, 
however, I admit to not having all the answers, or having thought 
through all the implications.

-Eric.

> Martin.
>
>> -----Original Message-----
>> From: Eric Johnson [mailto:eric@tibco.com]
>> Sent: 29 October 2010 00:52
>> To: Anish Karmarkar
>> Cc: sca-assembly@lists.oasis-open.org
>> Subject: Re: [sca-assembly] NEW ISSUE: Need some notion of "callback"
>> address in conjunction with eventing
>>
>> Hi Anish,
>>
>> On 10/28/10 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.
>> Sounds like you might be thinking about this one differently than I.  My
>> notion is that if a consumer receives a message with some sort of
>> "reply-to" address on it, then how do we model that in SCA?  And how
>> does that carry down into the implementation type?  Is this a notion of
>> an "unbound" producer that get the information associated with the
>> message delivered to the consumer, or is it a special "producer" object
>> that arrives with the message on the consumer side?  I was thinking we'd
>> model this as an actual "producer" on the component, but that somehow we
>> have to flag that the producer is used specifically for sending to the
>> "reply-to" address received when a message is consumed.
>>
>> I'm not sure of the best way to make this work, I just raised the issue
>> because I noticed we couldn't really address it with the current draft.
>>
>> -Eric.
>>
>>> 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
>> ---------------------------------------------------------------------
>> 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
>>