[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
Maybe I misunderstood the requirement, but I thought you were asking for a reply "event" to be sent to the reply-to destination given in the consumed event. Therefore no wiring needed to be done by the assembler. Martin > -----Original Message----- > From: Eric Johnson [mailto:eric@tibco.com] > Sent: 01 November 2010 20:00 > To: Martin Chapman > Cc: Anish Karmarkar; sca-assembly@lists.oasis-open.org > Subject: Re: [sca-assembly] NEW ISSUE: Need some notion of "callback" > address in conjunction with eventing > > Hi Martin, > > Well, in the case of JMS, it has built in support for a "temporary" > response channel. Also, there's nothing that says that the reply goes > back to a specific consumer on the specific component - it could very > well go back to a different channel. > > I don't understand your point about why the "reply-to" producer can't be > connected to two different channels, or have an implied temporary > response queue.... > > -Eric. > > On 11/1/10 8:53 AM, Martin Chapman wrote: > > I'm not arguing that it's not a good use case or trying to belittle JMS;-) > > I think the point is I don't see what an assembler can do if a component > has one of these "reply-to" producers. It cannot connect it to any channel, > and I can't think of anything else that the assembler might want to do. > > > > Martin. > > > >> -----Original Message----- > >> From: Eric Johnson [mailto:eric@tibco.com] > >> Sent: 29 October 2010 20:29 > >> To: Martin Chapman > >> Cc: Anish Karmarkar; sca-assembly@lists.oasis-open.org > >> Subject: Re: [sca-assembly] NEW ISSUE: Need some notion of "callback" > >> address in conjunction with eventing > >> > >> 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 > >>>> > >> --------------------------------------------------------------------- > >> 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]