Conversation management and JBPM integration is still being worked on, however web services that don't use this particular feature should be fine to use.
Yeah, we unfortunately had to slip the conversation management stuff to the next release, but it is now possible to implement a WebService in Seam (finally).
Not trying to criticize the good work that is being done with Seam, but just curious as ever: can anyone comment on the choice to add a conversationId element in the Soap header? This is documented as:
So how are conversations propagated between web service requests? Seam uses a SOAP header element present in both the SOAP request and response messages to carry the conversation ID from the consumer to the service, and back again.
The downside is:
Unfortunately, because web services may be consumed by a variety of web service clients written in a variety of languages, it is up to the developer to implement conversation ID propagation between individual web services that are intended to be used within the scope of a single conversation.
The Sun JAX-WS reference implementation supports statefull web services by using a different endpoint reference for each client. The good thing about this is that, for example, .NET 3.0 clients seem to support this out of the box as well.
It seems JBossWS 2.1 supports this through WS-Adressing as well; for example JBoss' Heiko Braun wrote: "WS-Addressing is the right way to build conversational web services".
Someone's question in the WS forum about future support for StatefulWebServiceManager has not yet been answered: JBossWS JAX-WS question using stateful. I cannot find any reference to this in JIRA either.
What we really wanted to use for this stuff was WS-Contexts, but JBossWS does not implement it yet. Shane tried to use WS-Addressing but it didn't work out (not sure of the details) and eventually he decided to do it this way after talking to the JBossWS folks.