XML & Web services: Web Services Conversation-Workflow-Choreography
- Posted by: Balakrishnan C
- Posted on: August 08 2002 07:49 EDT
I am looking for your view, comments, experience sharing regarding the Web Services Conversation / Flow / Workflow / Choreography.
There are several relevant specifications being developed such as : BPML, WSCI, WSFL, XLANG, BPSS, WSCL, Forthcoming Webservices mapping for EDOC, BTP
The Conversational, Transactional aspects and as well as the inter-relation of the WS are the things that seem to be missing from the current specifications and these are the ones addressed in part or fully by the above proposals.
What we have today are a set of interfaces exposed through Web Services Description Language (WSDL). What is left out from these which the above specs are trying to address are:
- Order of execution.
- Runtime handling of Exceptions \ Faults.
- Inter-relationship between service interfaces.
- Correlation between the messages exchanged between these services and as well as with their clients.
- Runtime middleware approach which handles the proper and automised execution of a set of Service interfaces (through the help of flow description with rules applied and maintainance of the context of execution)
The main issues that needs clarity before these are developed and deployed in real world scenario( and not just fictious flight reservation systems) are :
1. Is this a feasible/practical approach to add another layer of complexity. Doesn't the flow description further call for a heavy middleware gateway approach to access a set of Web Services. Will this not become critical spot for the successful utilisation of the Web Services
2. Can the execution of the WS interfaces really be automised through composition declaration (Flow). Considering the fact that these Services are developed over the Web by several parties. (Probably feasible for closely inter-related businesses.)
3. Can the traditional flow techniques be applied to Web Services ? As they are supposed to be develop not just by one party and probably will not follow a common convention on the message structures. The Mapping seems to be the solution, but how much of incompatibility will these flow mechanisms be able to handle.
4. There are features such as dynamic service lookup and composition within a flow systems, these seem to be too far fetching, maybe a feasible thing with a specific domain and in closed circle of inhouse defines set of service interfaces.
5. The flow systems handles the faults and exceptions within transactions through compensations whose implementation is directly provided by the service interfaces. This means that the service interfaces prior to the inclusion within a flow should already address these. Then what is the added advantage these flow languages provide. Can this similar effect be done through Messaging conventions and client system implementation rather moving the logic to a server side ?
Thanks for your view and comments in advance
With best regards,
There is apparently still confusion between public choreography interfaces and private implementation (aka Web Service Orchestration) involving the aspects of your question. While the first is up to the big guys to converge on and help the market consolidate into a single standard, the second is where innovation and complexity containment will be accomplished. For example, check out this post on TSS: http://www.theserverside.com/home/thread.jsp?thread_id=13814
Thanks Doron for the links,
As we discuss we have yet another specification in this area this time this is submitted by IBM, BEA & Microsoft Web Services Execution Language Which is considered to preceed the XLANG and the WSFL in a more elegant manner. This comes with a set of other two specification related to WS-Coordination and WS-Transactions. Don't we really have bigger soup bowl for Web Services. Mine is overflowing now :-)
I guess these are some signs of convergence.
Here is a link for more details : http://www.nwfusion.com/news/2002/0808web.html
We still see a certainly level of gap before these can be used in a real Business Process Automation Systems.