axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sanjiva Weerawarana <>
Subject Re: [Axis2] Implications of WSRM interfaces on Axis2 ClientAPI
Date Sun, 30 Oct 2005 10:42:33 GMT
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 ;).


View raw message