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:
 

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.