On Sat, 2005-10-29 at 15:27 -0600, Paul Fremantle wrote: > Guys > > I agree we don't want to add RM specific APIs to Axis2. However, as I > think my long post, and Chamikara's much neater append point out, > there is a way of looking at these as being general concepts in WS and > not specific RM concepts. In fact the Key concept is something that > the Sandesha guys invented and is not part of the RM spec. I believe > that the same Key and Last Message concepts could also help when you > switch on WS-SecureConversation. They are just basic ideas about how > WS works when not everything is a single call and we start building > conversations. > > What is driving this is a belief in COMPOSABILITY. Composability > should mean not having to change my code for a given WS-* standard. > But it also means that the core model has to support composability. > WS-Security was lucky, we didn't need to change any code, but its also > inefficient, so we've had to invent SecureConversation. I think that > the idea of sequences and conversations are generic new change the > core model of WS and should be reflected in the Axis2 API. > Paul
Absolutely +1! The larger point here is that interacting with a Web service is a much richer kind of experience than a single RPC style invocation. Clients of Web services effectively engage in a conversation with the service spanning many single message exchanges (aka operations), possibly lasting a long time (in wall clock speak). Similar to the proposed client side API change, a server side API may be needed for the service to inform the container when its done. Otherwise the runtime doesn't know when a service is done when the service is implemented in a non-service oriented language like Java. If its written in BPEL then there's no problem because one knows exactly when the service is "done". Ah my favorite BPEL again ;). Sanjiva.
