[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-rx] AS need for ordered delivery?
Marc, I think making WSRM DA free would be a fine way to go, but it would solve only part of the problem. One of the important things related to reliable messaging is DAs (irrespective of whether it affects messages sent on the wire on not). The application, AS and AD rely on those semantics (and we already have usecases documented for that). One could envision completely eliminating DAs from WSRM but then one would have to invent additional mechanisms (layered on top of WSRM) so that AS and AD don't have to worry about the DAs just as WSRM allows them to be worry free about (at-least-once) reliability. But the solution [1] to address this need seems to be fairly simple and does not complicate the protocol, IMO. It would go a long way in satisfying the developer/user community needs, and they are looking forward to the WSRM spec to do so. The TC has already resolved issue i009 to include DAs in the policy assertion. This means that DAs are not private to the RMD/AD, although they don't affect the messages and are implemented by RMD/AD. The question isn't: why would AS need to send a message in order if the AD didn't require it? but: how does the AS indicate to the AD/RMD the DA for a Sequence that it (AD/RMD) already supports/requires. Consider the case where the AD/RMD supports multiple DAs and declares them using wsp:ExactlyOne. How does the AS indicate to the AD/RMD which particular DA (of all the DAs the AD/RMD supports) is in effect for the Sequence. There are two additional interesting case: 1) RMD intermediaries: The CS/CSR message set up the sequence. CS/CSR messages are signaling messages and do not indicate which operation is being invoked. An RMD intermediary will not know at that point which DA to use. 2) What happens when a DA is advertised in a WSDL and it applies to out messages? Essentially the service is acting as a AS/RMS for those messages but is asserting a DA. Overall, I see DA as an important issue for the dev/user community, the solution seems rather simple and does not introduce additional protocol messages/elements. It seems like the cost/benefit ratio is quite low (much lower than the CloseSequence functionality that we have introduced, IMHO). If we don't address DAs then the users/dev community has to figure out how to layer this on top. -Anish -- [1] http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200510/msg00263.html Marc Goodner wrote: > I'm retitling the thread because this issue and AI are closed. > > Why would an AS need to send messages in order if the AD didn't require > it? If the AD does need ordering it would request it of the RMD and the > AS/RMS shouldn't need to care about the DA in effect as it has been > taken care of at the destination. > > > -----Original Message----- > From: Gilbert Pilz [mailto:Gilbert.Pilz@bea.com] > Sent: Tuesday, October 25, 2005 8:58 PM > To: Duane Nickull; Anish Karmarkar; Marc Goodner > Cc: ashok.malhotra@oracle.com; ws-rx@lists.oasis-open.org > Subject: RE: [ws-rx] Proposal for AI 40 and i024 > > I'm not sure if asking an RMD what DA it purports to provide is > necessarily asking to "see beyond it". If I have an application that > relies upon ordered delivery to function correctly and I deploy that > service onto an infrastructure with an RMD implementation that > can't/won't provide ordered delivery clearly I have made a mistake. The > question is do I want that mistake to surface as a exception the first > time a client tries to invoke the service (hey dude! this thing can't do > ordered delivery!), or would I like the mistake to surface in all sorts > of bizarre behaviour by the application? > > - g > > >>-----Original Message----- >>From: Duane Nickull [mailto:dnickull@adobe.com] >>Sent: Thursday, October 20, 2005 5:37 PM >>To: Anish Karmarkar; Marc Goodner >>Cc: ashok.malhotra@oracle.com; ws-rx@lists.oasis-open.org >>Subject: RE: [ws-rx] Proposal for AI 40 and i024 >> >> >>My sense of the F2F resolution was that the TC wanted to >>capture the fact that DAs, timeouts etc were "observed" >> >>Anish: >> >>I do not think they really are unless the RMS can see past >>the service. >>This is bad architecture IMO. Talk to the interface but >>don't try to see beyond it. >> >>D >> > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]