WS-BPEL Extension for Semantic Web Services (BPEL4SWS)

Posted by Boris Lublinsky on Nov 30, 2008

Sections

Architecture & Design,

Enterprise Architecture

Topics

SOA ,

Business Process Management ,

Semantic Web

Tags

OMG ,

WS-BPEL

The Web Services Business Process Execution Language, version 2.0 (WS-BPEL 2.0 or BPEL), defines an orchestration model for interactions among different Web services based on partner links (definition based on WSDL 1.1). The language encompasses features needed to describe complex control flows, including error handling and compensation behavior.

One of the limitations of the language is the requirement to use partner links to define a target Web Service, which leads to point-to-point communications between a process implementation and a service. BPEL for Semantic Web Services (BPEL4SWS) is trying to overcome this limitation through usage of Semantic Web Service Frameworks to define a communication channel. Instead of explicitly specifying activity, it enables its description in a much more flexible manner based on ontological descriptions of service requesters and providers. The specification

introduces an extension to BPEL to enable describing interaction using semantic Web service Frameworks instead of using WSDL 1.1. Semantic Web services (SWS) can be considered an integration layer on top of Web services; they use ontologies as data model and they have a rich conceptual model. There are efforts towards standardizing this conceptual model within the Reference Ontology for Semantic Service Oriented Architectures (RO4SSOA)

It formalizes the concept of a service described in terms of its interfaces and its capability,as in the SOA-RM (Reference Model for Service Oriented Architecture). In contrast to the SOA-RM it also explicitly models the required capability and possible interactions of the service consumer. The concept used to contain these descriptions is called a goal.

The core of the specification introduces a "WSDL-less interaction" model based on the newly introduced concept of a conversation:

A conversation is a WSDL-less abstraction of a partner link: Instead of referring to a partner link type, a conversation refers to either a goal or a Web service description defined according to the RO4SSOA

Support for conversations is based on a several new types introduced by the standard:

BPEL4SWS defines new activity types to define the message exchange with partners: the that represent WSDL-less receive, reply and invoke activities; a WSDL-less activity; and a WSDL-less . The activities can be grouped using a element. This way a BPEL4SWS process can be involved in long-running multi message interactions with partners. Conversations can be grouped using a element. This way it can be defined that multiple conversations have to be conducted with a single partner.

BPEL4SWS conversation is concerned with solving a certain kind of problem, e.g. booking a flight. There are two roles in every conversation - one partner provides the functionality to book a flight which is described via the concept of a service according to the RO4SSOA and the other partner wants to use/consume this functionality which is described via the concept of a goal. As a result, BPEL4SWS distinguishes between providing and consuming conversations. On a providing conversation the process offers functionality to partner services and on a consuming conversation a BPEL4SWS process wants to use functionality provided by a partner service. Providing conversations are described using a service description. Consuming conversations are annotated with goal descriptions, the attached goal. Goal description is used to discover a corresponding Web Service. In case no Web Service has been discovered, a noServiceFound Fault has to be thrown.

Conversations in BPEL4SWS are described using concepts of the RO4SSOA:

The RO4SSOA builds a layer on top of Web services. It abstracts from technical details and provides a description of service requester and service provider that not only focuses on the interface but also describes the capability of a service in terms of assumptions and effects... Frameworks that implement the RO4SSOA require a middleware component that provides the following functionalities:

• Goal-based service discovery
• Management of the life cycle of a communication between service requester and service provider.
• Endpoint(s) for receiving data from both, service requester and service provider.
• Means to invoke both, service provider and service requester.

Although the specification is still in a very early stages, BPEL4SWS being provided "as-is and for review and evaluation only", it provides a direct path for integration of service orchestration with semantic web services, which in turn can enable significantly more complex service interaction patterns, which are better match for the real business scenarios.

• Older >