Previous Section Next Section

Future Service Description Efforts

WSDL is the basis for service description, but it is not the only component. WSDL describes details of invocation syntax. There is more to describe about a Web service than just the IDL-level details. At this point, higher level description mechanisms layered on top of WSDL are still emerging; no standards exist in this space.

Web Services Endpoint Language (WSEL)

As part of the Web Services Flow Language (WSFL) specification (, IBM hinted at a new language, based on WSDL, to describe non-functional characteristics of a Web service. IBM calls this language Web Services End-point Language (WSEL).

The purpose of WSEL is to formally model non-functional characteristics of a Web service—things like quality of service (QoS) statements, privacy policy, auditing policy, and so on.

These items do not directly affect the syntax of the message (certainly not the core part of the message), but they can affect whether the service requestor chooses to collaborate with a particular service provider.

This level of service description is especially important for asynchronous message flows. For example, a WSEL-specified property of the Web service could include the expected response time, possible duration estimates for the interaction, or number of acceptable retries. This would be the basis upon which the requestor could establish time-out behavior and safely assume that the collaboration will not complete and execute whatever rollback or compensation mechanism is associated with the interaction.

Other standards are emerging in this space, not directly based on WSDL, including work done surrounding the collaboration protocol profile and agreement markup language (cppML) from the ebXML effort (, and DAML-S from the group (

Watch this space. End-point modeling is one of the next big areas for standardization within Web services.

Web Services Flow Language (WSFL)

The final layer of the service description stack is the flow layer or orchestration layer. It is this layer of specification that the WSFL addresses.

WSDL is used to describe the detailed information necessary to invoke a Web service; a single Web service, WSDL has no notion of sequencing several Web service invocations or ordering the operation invocations within a single Web service.

The Web Services Flow Language (WSFL) builds upon the work in WSDL, describing how to organize and orchestrate a series of Web services invocations into an overall business process or workflow. You would use WSFL to model long-running multistep business collaborations between multiple business partners.

IBM published the WSFL specification in May 2001. It is IBM's intention to partner with other organizations to standardize WSFL. There are other mechanisms to organize and orchestrate Web services. Microsoft, for example, defines a similar language called XLANG. It is difficult to predict how the industry will address these two approaches to Web services orchestration or whether they ultimately will converge to one standard. This book, however, will briefly describe how WSFL can be used as part of the overall service description stack.

WSFL is an XML language somewhat similar to WSDL. WSFL is used to orchestrate, or organize, the sequencing of Web services invocations. With WSFL, you can:

  • Describe a business process that is composed of a sequence of activities, some or all of which might be Web services

  • Describe the business process itself as a Web service, specifying the relationships between various role players in the workflow

The exciting aspect of WSFL is that it allows new, higher-level Web services to be created by combining or orchestrating other Web services. So, the more Web services that are created, the more possibilities there exist for orchestrating them into more powerful Web services. This enables a network effect to occur, making Web services a very powerful concept for business process integration.

WSFL leverages the portType element from WSDL to define the basic component or activity interface in the workflow system. The business process is then modeled as a state machine, where activities are modeled as Web service invocations and the invocations are sequenced by state transition events (control flow). Eventually, as more organizations adopt Web services and publish Web services for partner consumption over the Internet, we will see standard portType or service interface definitions emerge, thereby allowing organizations to incorporate and integrate their partners' business processes into their own workflows. Until these standard service interface definitions begin emerging, we will see WSFL used predominantly for orchestrating internal business processes and activities.

So, watch the Web services orchestration space, too. The final piece of the Web services puzzle will appear when it is possible to model a business process, including sequencing, compensation mechanisms, branching, and so on, using a standard supported by a variety of third-party tooling. Furthermore, because Web services technology fosters process integration between business partners, Web services orchestration standards will allow an organization to formalize how it collaborates with its business partners.

Completion Criteria for Web Services Standardization Efforts

With the advent of WSEL and WSFL augmenting WSDL, we observe a very important pattern emerging. Given the assertion that all Web services technologies must follow the naming pattern WS*L, we can conclude that when 26 specifications are standardized, one for each letter of the alphabet, then Web services will be "done" graphics/doll.gif.

    Previous Section Next Section