It's the rule of BPEL4WS to define a new Web service by composing a set of existing services through a process integration-type mechanism with common language control. BPEL4WS is basically a language design to implement the compilation of processes that indicate how the services interface abstractions into the overall execution of the process composition. Indeed, it's designed to be a standard language for process integration. The interface is described as a collection of WSDL portTypes, as is any other Web service (for more information on WSDL, see Chapter 15). BPEL4WS leverages the concept of message properties used to identify relevant data embedded in messages. Using this mechanism, properties may be viewed in two ways: transparent and opaque:
The effect of opaque data appears within nondeterminism in the actual behavior of services involved in the business protocols; for example, when creating a protocol to define the purchase of a stock. The broker has a service that receives an order request and responds with either a confirmation of the transaction or a denial, using any number of criteria (e.g., price, number of shares, or buyer's credit). Indeed, the decision process is opaque, but the fact of the decision must exist as a behavior in the business protocol. In essence, the protocol acts as a "switch" within the behavior of the broker's service, although the selection of the branch taken is nondeterministic. To this end, the application of nondeterministic behavior can exist by allowing assignment of the nondeterministic or opaque value to a message property. Thus, the property can then be exploited in defining conditional behavior that captures behavioral alternatives without exploiting the decision processes. The end result is the ability to expose a process to the public, while hiding aspects of the service you would rather not expose to the public.[2]
The applications of this should be readily apparent from our discussion of public versus private processes. Using this mechanism you'll be able to expose behaviors, but can hide any aspect of the service from outside users, typically other organizations. Thus, you can expose a service with assurances that private or proprietary information won't fall into the wrong hands, or be invoked erroneously. BPEL4WS defines a model and grammar for describing the behavior of a process using the interactions between the process and its partners. These interactions with the partners occur through Web services interfaces, and the structure of the relationships at the interface level exists in an entity known as a service link. It's the job of a BPEL4WS process to describe how these services interact with these partners, defining a more holistic business process, including coordinating logic (sequencing, subprocesses, nesting using outside services, etc.). Within this standard we are able to deal with exception processing and define how individual or composite activities within a process are compensated in cases where exceptions occur. There are two major concepts to remember when considering BPEL4WS in the context of application integration:
BPEL4WS exists as an extension of many XML specifications, including:
|