On the TSS Interop blog, Scott Balmos has given us an example of a stateful web service. He'd done it on the Interop blog with an EJB reference before, but using a recent build of JAX-WS, he's gotten it done without hacks... and shows the server code in Java, with the client using the stateful service from C#. The previous entry used "an underlying session management system [providing] a session ID or token, which is then passed in every subsequent SOAP method call." The new example, however, uses a SOAP Session Factory: All of this requires fairly recent builds, but Scott says it should work in Glassfish v2 and WebLogic 10. It's almost magical how easy the code is, to use a stateful SOAP service in this manner. Any thoughts on possible uses/problems?

Stateful communication, or Stateful Service, or Stateful SOAP? I wonder. William Martinez Pomares

If you want to be truly specific, then the best selection is that it's a Stateful Service. The communication is most definitely not stateful, as this is running over HTTP without session cookies or anything else HTTP-based. SOAP is not stateful, and this code runs on a per-service basis. As I note in the blog entry, on the wire the state management uses WS-Addressing to create a reply-to SOAP header entry with the JAX-WS stateful session ID as additional metadata. Then WS-Addresssing-compliant SOAP stacks know to use that given reply-to address and attached metadata in all further SOAP messages. --S

I wander if anyone is actually waiting for this. When would it be interesting to use a stateful Web Services? When we want several web services working together. But isn’t there already a standard available that handles this: WS-BPEL. Kind regards, Gregory

One way to look at this is that this brings in the same abstraction improvement C struct -> C++ class. When emulating object-orientation in C, functions tend to take the data that it acts on as the first argument. Similar thing happens often in web services. They take IDs or other identifiers as the arguments. When you define a class in C++, all it's doing behind the scene is to create a structure and every method simply gets implicit 'this' parameter. This is exactly doing the same. EPR serves as that implicit 'this' parameter. So the end result is that proxy.foo(id,param1,param2,...) becomes proxy.foo(param1,param2,...) The proxy object represents the 'id' parameter. I think this makes the programming easier.

Looks as great as Microsoft breaking 8+3 limit in filenames. Congratu.la~001 Guido.

Any thoughts on possible uses/problems?

I tend to favor keeping state on the client for scalability reasons.

I wrote something that does basically the same thing using OpenLaszlo as the RIA, the CXF Stack that interfaced with POJOs, and Terracotta to persist / cluster the POJOs here: http://javathink.blogspot.com/2006/10/build-ajax-soap-app-in-15-minutes-part.html NOTE: I work for Terracotta :)