Meu cantinho

After 5 and a half years, I am very happy to announce that WSDL 2.0 is in Proposed Recommendation. I extend many thanks to everyone who worked so hard and persevered to get us to PR, especially our chair, Jonathan Marsh.

The PR documents are at the following URLs:

• 23 May 2007: Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language - Proposed Recommendation Review Ends 20 June 2007
• 23 May 2007: Web Services Description Language (WSDL) Version 2.0 Part 2: Adjuncts - Proposed Recommendation Review Ends 20 June 2007
• 23 May 2007: Web Services Description Language (WSDL) Version 2.0 Part 0: Primer - Proposed Recommendation Review Ends 20 June 2007

In addition the auxiliary specs (which are also complete but not being taken through the official voting process to issue them as Recommendations) were republished.

• 23 May 2007: Web Services Description Language (WSDL) Version 2.0: Additional MEPs
• 23 May 2007: Web Services Description Language (WSDL) Version 2.0: RDF Mapping
• 23 May 2007: Web Services Description Language (WSDL) Version 2.0 SOAP 1.1 Binding

At the OASIS Symposium 2007, Andrew Towney of Archistry Ltd. gave a scintillating presentation on how organizations attempt to respond to change in the business environment from the perspective of Service Level Agreements (SLA). In particular he gave a very interesting perspective on the thought process around software systems and their delivery. His “Is ‘REST API’ an Oxymoron?” post is a good introduction into this from a technology perspective.

What I found most interesting is his idea of SLAs and how they need to represent not only the SOA concept of a "Service", but also the contracts between particular services which are not captured therein. We have been so accustomed to speaking of WSDL portTypes as services that it is easy to forget that this has an entirely different meaning in the context of SLA. Further thought and discussion points to Abstract BPEL providing a way to capture these contracts at least at a bilateral level, that is the contracts between partners.

Furthermore, there are SLAs which may need to involve multilateral contracts. Some business activities involve >= 3-way interactions between parties. In such activities, the SLA not only includes the observable or template behaviour of the orchestrations (rather than simply the WSDL), but the fact that some interactions are going on external to one's orchestration domain.

For example, party A interacts with party B and party C, and party C interacts with party B as part of their contracts with party A. A's completion of its business activity depends on the interaction between C and B. A sends requests to B and C. Figure 1 below represents this in a graph format:

Figure 1: Multi-lateral business activity.

As part of the SLA, A must allow B 10 minutes time to provide a response, which is based on Party A's request with B and the request C sends (triggered by the request it receives from A) to B. If B does not respond in 10 minutes, responds negatively or throws a fault, A must interact with an alternate B provider. If C does responds negatively or throws a fault, A must interact with an alternate C provider. These alternates are mutually exclusive per the SLAs between the parties.

However, B may not respond because of a breakdown in its interaction with C. This affects the alternatives A needs to choose - A must choose an alternate for C. From the A->B interaction, B holds some context which is session specific and not idempotent, and choosing an alternate for B will result in a duplicate request for the same session. Moreover, the SLA is such that C doesn't have a timeout for providing a response or fault.

In this case it is important that A have reported to it the reason any B timeout occurred. While this is straightforward to capture in fault handling, it is critical that this is captured as well in the definition of the SLA used in operation. While this example may seem contrived it is represented in a large number of business activities, in verticals such as finance, manufacturing and telecommunications.

Here the SLA must represent a multi-lateral perspective. Without representation of the results (or lack thereof) of interaction between B and C, A is unable to properly address all failure scenarios. Representing the interactions outside the bi-lateral perspective is critical to A deciding when to properly seek an alternate provide for B and/or C.

While Abstract BPEL captures the bi-lateral perspective, it must be used with a description which encompasses the multi-lateral perspective. This is where choreography and business transaction descriptions such as CDL and ebBP become useful. By describing the multi-lateral aspects, they can combine with Abstract BPEL to provide a complete description of the SLA. From such descriptions, tools such as audit and monitoring can provide user-friendly views into the states of such business activities.

With WS-BPEL and WS-TX  (WS-Coordination, WS-AtomicTransaction, and WS-BusinessActivity) accepted as OASIS standards these past two weeks, the question has arisen as to how they interoperate and whether there is any overlap between the two.

As WS-BPEL is a language for describing the logic to orchestrate Web service orchestrations, it defines a compensation model, but transactional semantics and properties are not defined for Web services. The latter are needed in order that Web services can be matched not only on services offered, but also on the supported transactional properties. WS-BPEL allows for compensation for the process to be invoked in some implementation specific manner, WS-TX (in particular, WS-BusinessActivity), being one such option.

The BusinessActivity protocols handle long-lived activities and the desire to apply business logic to handle business exceptions. These coordination protocols are required when interoperating across vendor implementations and provide support for a variety of business process behaviors such as those found in the WS-BPEL.

As such, it is important for WS-BPEL to interoperate with additional transactional specification languages, in particular the work on WS-TX. There is work left to be done here, but WS-BPEL 2.0's expansion of the compensation model along with WS-TX 1.0's release makes this more likely than not.

Today the WS-BPEL TC has approved WS-BPEL 2.0 as an OASIS Standard, the highest level of ratification in OASIS.

BPEL is already the industry foundation for orchestrating Web services. WS-BPEL 2.0  is an important milestone that represents a significant evolution of the original specification. WS-BPEL enables users to build and deploy successful Web services and SOA projects that scale with the organization as they add new partners, customers and services to their infrastructure.

WS-BPEL defines a model and grammar for describing orchestration behaviour based on interactions between a process and its partners through Web services interfaces. A WS-BPEL process defines how multiple service interactions with these partners are coordinated to achieve a business goal, as well as the state and the logic necessary for this coordination.

WS-BPEL separates the observable aspects of business process behavior from its executable details - supporting both executable processes, which describe the actual behavior of participants in
business interactions, and for abstract processes, that may be used to represent publicly observable behaviors. Abstract processes serve a descriptive role and allow for more than one possible use case.

The Open SOA Collaboration announced that it is advancing its recently published Service Component Architecture (SCA) v1.0 specification to OASIS for standardisation. SCA simplifies the creation and composition of services, critical to building applications using services based on an SOA approach. The Open SOA Collaboration includes among its members BEA, IBM, Iona, Oracle, Redhat, SAP, Siemens, Sun, Sybase and TIBCO.