[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'm missing something. Events are all about loosely connected entities, If you want to use 'replyTo' why not use Services/References? All the best, Ashok On 11/1/2010 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]