Re: Addressing Orchestration

I agree with Ugo that the Web Services Architecture working group ideally should
be working up a conceptual architecture that could form the framework from which
individual work efforts relating to web services will be launched. 

However, I also agree with Dave Orchard that this is a daunting task for the Web
Services Architecture working group, and that they already have a lot on their
plate. Therefore, I think that the best forward is to establish a Web Services
Choreography working group, as it has already been discussed, and use that
working group to seed the work on the next level up of the architecture. 

The currently existing Web Services Description working group is in essence
concerned with describing a set of web service operations, or stated differently
a static web service. This is an  absolutely necessary foundation for anything
more complex that one might want to do with web services. However, we are now
ready to move beyond static web services, into
stateful web services that may have complex usage scenarios. 

It is this space that a choreography working group should be addressing. 

How does one define the supported usage of a stateful web service?  In essence
this means defining a number of relationships between individual operations. 

What are the allowable sequences of usage of those operations?  

What are the relationships (correlations) between the data exchanged? 

What are the transactional semantics (if any) of a sequence of operations? 

How would one compensate for a sequence of operations, since atomic roll-back is
not relevant. 

What are the exceptions that may prevent a sequence from completing, and how are
those
exceptions handled? 

All of these aspects of a stateful web service need to be formalized and
described in an unambiguous and coherent syntax in order for web services to be
adopted for anything beyond the most atomic usages. 

This is the challenge of the next layer of the web service stack, on top of
WSDL, and the web services architecture working group should start meeting this
challenge, either directly, or indirectly by recommending a new choreography
working group.

-- Mark


> Ugo Corda wrote:
> 
> Hi everyone,
> 
> Since I just joined the WSA WG, I thought of warming up for the task by asking
> a question prompted by the recent publication of the WSCI
> spec(http://wwws.sun.com/software/xml/developers/wsci/).
> 
> It looks like Orchestration/Choreography/Workflow proposals relevant to Web
> Services are proliferating in the industry. The ones that come to my mind are
> IBM's WSFL, Microsoft's XLANG, BPMI's BPML, ebXML's BPSS, HP's WSCL, and now
> WSCI.
> 
> My hope is that clarity will soon be made in this important area(s) of Web
> Services utilization. As usual, lack of clarity increases the risks of slow
> adoption of, or resistance to, Web Services technologies in many parts of the
> industry.
> 
> I wonder if WSA could play a role in this area, at least from the point of
> view of establishing a conceptual and architectural framework within which the
> various proposals can be positioned, discussed, compared and selected. (Please
> understand that I am not talking about discussing specific proposals and/or
> establishing profiles, a role which is already being played by other
> organizations, e.g. WS-I).
> 
> I looked at the Requirements document and it does not seem to mention
> Orchestration or use any similar word. Browsing through the archives of this
> WG, I see that the subject of Orchestration has been raised a few times in the
> past, but my impression is that no final decision was reached regarding
> whether or how to address it. If that is the case, the recent publication of
> yet another Orchestration spec could be the opportunity for the WG to put a
> stake in the ground in this particular area.
> 
> Regards,
> Ugo
> 
> Dr. Ugo Corda
> Standards and Product Strategies
> SeeBeyond Technology Corporation
> 404 E. Huntington Dr., Monrovia, CA 91016
> (626) 471-6045 -- phone
> (626) 353-4851 -- cell
> (626) 471-6021 -- fax

Received on Tuesday, 25 June 2002 01:20:56 UTC