[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
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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]