Sample Web Process and support of different standards to model the process

    Lets consider an example for a typical web process in e-business domain, an electronic toy manufacturer processing a distributor's order. When the distributor places an order, the manufacturer checks the inventory to verify if it has enough goods to satisfy the order. In case there is enough stock then the manufacturer contacts its delivery partner for a date of delivery and its agreement database or accounts dept to fix price for the order. The delivery date and the agreed price are returned to the distributor. In the other case when there is not enough stock in the inventory, the manufacturer contacts its supplier partner for the required components. Then he contacts its delivery partner to arrange for delivery of components to its manufacturing site and later to deliver the products to the distributor.

    If this order processing is implemented by the Manufacturer as a workflow of Web services, it can be done using BPEL4WS, BPML or DAML-S. All of these standards support modeling the flow specification of web services in a process. In BPEL it can be implemented as an executable process. BPEL4WS takes the perspective of the Manufacturer to implement this process. Other involved parties like the distributor, the supplier partner and the delivery partner are viewed as partners of this process who either invoke the process or the services that are invoked by the service. This dependency is established using the service link types. The basic activities in BPEL receive/reply and invoke help in handling messages from the partner and sending messages to the partner respectively. Each of the partner and the process take respective roles defined by service link type that represents collaboration. This is achieved by referencing to port-types contained in WSDL interface definition that are to be supported by the partners. A service that implements this port-type interface definition can act as a partner to the process. Different activities in BPEL pass information among them using global data variables. In addition to these, BPEL also has constructs to handle transactions and exceptions using correlation set in BPEL and related standards WS-Coordination and WS-Transaction. This enables features like exception handling when the toy ordered by the distributor is not listed in the inventory and transaction management which allows multiple distributors to place order using the Manufacturer's system and it also helps messages from delivery/supplier partners to reach correct process instances. BPML has similar process flow constructs. In BPML, the <action> activity performs or invokes a single operation that involves the exchange of input and output messages. In the context of WSDL, operations are specified using Port type and operation. The action tag also supports representing correlation features. BPML also supports transactions, exception handling and recursive decomposition. In the above example if the fixPrice part is to be implemented as a process in Accounts department, BPML can be used to model this sub-process as a part of the Manufacturer's orderProcessing process as the parent process.

    The DAML-S initiative for semantic web services provides process model to describe the operation of a web service. To achieve automatic service operation and interoperation, DAML-S provides declarative specifications of the prerequisites and consequences of individual services. For a detailed perspective of services they are viewed as processes and represented using processmodel. The process model conceives each program as either an atomic process or as a composite process. A non-decomposable web service is described as an atomic process. If in the above example 'checkInventory' is non-decomposable, meaning that it can be executed using a single call, then it's process model will define it as an atomic process. The entire order processing process is decomposable as it is made of subprocesses (other atomic or composite processes). Hence the process model will define it as a composite process. The Process ontology that describes the process has 'Process' (name of a daml-class) as the primary kind of entity. It can have any number of inputs and outputs that respectively represent the information that is, under some conditions, required for the execution of the process and the information that the process provides, conditionally, after its execution. In DAML-S ProcessModel, inputs to the processes can be made either mandatory or optional and the outputs are generally conditional. For example given above, after processing the order the Manufacturer's e-process can either return a confirmation message on successful order processing with price and delivery details or other kind of unsuccessful order processing message with related details. To describe different output types, DAML-S defines conditional output class (ConditionalOutput) to describe a condition and an associated output. Since each activity in a process will have its own process model, potentially, every activity can have conditional outputs. In addition it will have parameters to specify the participants in the process and other declarative parameters for giving details. It can also have preconditions and effects associated with the process. The process upper ontology of DAML-S has also a minimal set of control constructs to describe the process. The semantics of the control constructs are similar to the semantics of the respective control constructs in BPEL, BPML or any other process modeling standard. DAML-S ProcessModel is meant to be agnostic of the process modeling formalisms like BPEL and BPML. Instead, it provides a general, canonical approach using vocabulary and properties for a process model to remain compatible with any process-modeling standard. After reprenting the order processing e-process using DAML-S, it can be made available for use. To access the order processing service it can be viewed as a black box whose internal components and the operation details are hidden to the end user. This is done by defining a "simple process" that charecterizes this black-box view and it can be related to the detailed composite process. While these standards provide constructs to describe workflow model (orchestration), they do not provide conversational model (choreography) that are common in collaborative business processes. Detailed discussion on standards that model collaboration are found below.

    Executable processes help in web service orchestration. Choreography of the collaborative business processes is defined using abstract processes. Abstract processes in BPEL are aimed to describe business protocols that specify the sequencing of messages exchanged by one particular partner with its other partners to achieve a business goal. The messages that are exchanged are based on some activities within internal business processes. When defining the abstract process the logic behind message creating and the logic behind branching condition need not be defined with respect to the business protocol data that defines the context of the process. Hence it need not describe the internal decision-making and data manipulation. Abstract business processes always operate on properties that are generic way to name and distinguish data elements in a message. In the above example if the message exchange with the delivery partner is as follows:

  1. From Manufacturer - To Delivery Partner : Date, location to Pickup and location of delivery.

  2. From Delivery Partner - To Manufacturer : Data of delivery and Price.

  3. Manufacturer makes decision.
  4. From Manufacturer - To Delivery Partner : Deal Confirmation.
  5. From Delivery Partner - To Manufacturer : Acknowledgement

    The above sequence of message exchanges can be represented as an abstract process. The protocol data would be the price and date the delivery partner sends to the manufacturer. The deal confirmation message could be based on a value of a variable that is non-deterministically assigned. The value is decided by the decision-making activity. It is not a visible behavior of the manufacturer's collaboration with the delivery partner. The abstract processes allow assignment of non-deterministic values to properties to model this. However, an abstract BPEL process defines the business protocol from the perspective of a single entity in the collaboration. While real world business collaboration need a peer-to-peer conversational model. Other standards like BPSS, WSCI and WSCL try to achieve this kind of model.

    The above listed message exchange sequence can be defined as a conversation from the perspective of the manufacturer and the delivery partner. WSCL models this kind of business level interactions using exchange of XML documents. The above conversation can be defined either as four one-way interactions or as a pair of two-way interactions (1,2 and 4,5). In either case the permissible sequence these interaction can be defined using transition elements. If the conversation supported by Manufacturer's system is made available then potential delivery partners can use this to figure out the conversation support expected from them. However WSCL does not specify the binding of these interactions to specific communication protocol. So the specification suggests three ways of combining the WSCL descriptions to the WSDL descriptions of the participating services. WSCL does not explicitly model roles of the collaboration. Hence if there is a standard collaboration pattern and if a service conforms to a role in collaboration. The role that it supports in collaboration cannot be modeled using WSCL.

    WSCI is like WSCL but provides a more comprehensive model for organizing the sequence of WSDL operations. In the conversation (message exchange) between manufacturer and delivery partner given above, the conversation is not limited to invoking a single operation. Hence a collaboration description is needed. For detailing the collaboration definition WSCI interface definition is embedded inside WSDL definitions. Correlation names can be be defined with the help of property 'deliveryId' to identify and correlate messages about the same delivery deal. If the manufacturer or delivery partner support different kind if interfaces the respective WSDL document can have multiple interface elements. Each interface has processes to model the observable behaviour of the the service in the context of that process. The action is the basic WSCI construct that identifies a unit of work associated with a given operation. Each of the operations receive delivery details and receive ack by the delivery partner can be different actions and can be defined for execution sequentially to properly handle message exchange. WSCI also provides ways to represent more than one logical role in the exchange. In addition it supports transactions, exception handling capabilities.

    In ebXML, the above-mentioned entire process can modeled precisely in all aspects. In the overall process both the distrbutor and manufacturer will provide information on what they can contribute to the collaboration. It clearly models the process with the auxiliary parties like deliveryPartner identified as intermediaries. The single step activity orderParts to suppliers may consist of individual sub-steps. To carry out the business transactions between the manufacturer and supplier partner and to choreograph the business transactions, the roles involved may be defined in a binary business collaboration specification. The transactions are mapped to the services that each partner (role) must implement. The above-mentioned example could be explained with the following steps:

  1. The Manufacturer can query the ebXML registry for business collaborations in BPSS that will suit his business requirements and assumes a role defined in that.
  2. The manufacturer implements/povides the interfaces to enable invocation of services that the choosen role in that BPSS is supposed to provide.
  3. The manufacturer creates a Collaboration Protocol Profile (using CPP schema) of the services that are made available and the details are published in a registry.
  4. The distributor can look up that registry based on his business needs, finds the CPP of the manufacturer and intermediaries (if needed).
  5. Negotiation (CPA) and agreeing on a contract is done using CPPs of the distributor and the manufacturer. CPA is between two parties and hence it is created for each intermediary with respect to both manufacturere and distributor.

These steps will automate the business process between the distributor and the manufacturer. In this way, with the use of BPSS, CPP and registries, ebXML standards propose standardising the processes and interactions between them.