[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-assembly] NEW ISSUE: Need some notion of "callback" addressin 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]