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

[Martin Chapman <MARTIN.CHAPMAN@ORACLE.COM>]

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.

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
>