Sample Web Process and support of different standards to model the process
The Business Process Execution Language for Web Services (BPEL4WS) is a language to specify business processes and business interaction protocols. It superseded XLANG and WSFL as a standard for web services flow specification. The model and XML-based grammar provided by BPEL defines the interactions between process and its partners that occur using Web services interfaces. It also defines the states and logic of coordination between these interactions and systematic way of dealing with exceptional conditions. The business interaction protocols are called abstract processes. They are used to specify public and visible message exchange between different parties involved in a business protocol and they do not reveal the internal behavior or the implementation of the involved parties. The executable processes on the other hand are like workflow descriptions represented using basic and structured activities specifying a pattern of execution of web services. The process model defined by BPEL is based on the WSDL based service description model. The services (described as partners in BPEL spec) that the proces invoke/reply using basic activity are represented using their WSDL description. An executable process itself can be a Web service by itself and the interface of that process can be represented using WSDL.
BPML provides an abstract model and grammar for expressing abstract and executable business processes. Using BPML, enterprise processes, complex web services and multi-party collaborations can be defined. A process in BPML is a composition of activities that perform specific functions. The process directs the execution of these activities. It can also be a part of composition by defining it as a part of its parent process or by invoking from another process. Each activity (both simple and complex) in the process has a context, which defines common behavior for all activities executing in that context. Hence a process can be defined as a type of complex activity that defines its own context for execution. The BPML specification defines 17 activity types, and three process types. The different process types are nested processes which are defined to execute within a specific context and whose definitions are a part of context's definition, exception processes to handle exceptional conditions in executing parent's process and compensation processes to provide compensation logic for their parent processes. Each process definition may specify any of the three ways of instantiating a process: in response to an input message, in response to a raised signal, or invoked from an activity or schedule. BPML specifications support importing and referencing service definitions given in WSDL. It also suggests standardizing BPML documents by using RDF for semantic meta-data, XHTML and Dublin Core metadata to improve human readability and application processability.
ebXML is a global electronic business standard envisioned to define a XML based framework that will allow businesses to find each other and conduct business using well-defined messages and standard business processes. ebXML Business Process Specification Schema is a standard for representing models for collaborating e-business public processes. Using XML syntax the parties involved in a collaboration can model and agree on the relevant business process. ebXML BPSS standard can be used to configure the business systems to support the commercial collaboration. Hence this specification determines the actual exchange (identified as patterns) of business documents and business signals between the partners. A library of process templates can be created using BPSS definitions and to support a business process template a user can extract information from the corresponding BPSS and configure his runtime system by agreeing on a pattern and a role that collaborates through a set of choreographed transactions by exchanging Business Documents. However there is no explicit support for describing how data flows between transactions, but there is explicit support for specifying quality-of-service semantics for transactions such as authentication, acknowledgements, non-repudiation, and timeouts.
DAML-S is an initiative to provide an ontology markup language expressive enough to semantically represent capabilities and properties of Web services. DAML-S is based on DAML+OIL and the aim is to discover, invoke, compose, and monitor Web services. It defines an upper ontology appropriate for declaring and describing services by using a set of basic classes and properties. In DAML-S, each service can be viewed as a process and its Process Model is used to control the interactions with the service. Using the processOntology’s sub-ontologies, ProcessOntology and ProcessControlOntology, it aims to capture the details of the web service operation. The ProcessOntology describes the inputs, outputs, preconditions, effects, and component subprocesses of the service. ProcessControlOntology is used to monitor the execution of a service. However, current version of DAML-S does not define the ProcessControlOntology. DAML-S also categorizes three types of processes. The first type is atomic processes which do not have any subprocesses and can be executed in a single step. The second type is simple processes which are not invocable as they are used as abstraction for representing atomic or composite processes to use them. Composite processes are of third type which are decomposable into sub-processes. The composite process uses lot of control constructs to specify how inputs are accepted and outputs are returned by subprocesses.
The Web Service Choreography Interface (WSCI) is a XML-based language for description of the observable behavior of a Web service in a message exchange in the context of a collaborative business process or workflows. It defines the flow of messages exchanged by a stateful Web service describing its observable behavior. By specifying the temporal and logical dependencies among the message exchange it is used to describe a service in such a way that other web services can unambiguously interact with it conforming to the intended collaboration. Though it provides a message-oriented view of the process, it does not define the internal behavior of the web service or the process. It complements the static interface details provided by the WSDL file by describing the way operations are choreographed and its properties. This is achieved by using the dynamic interface provided by WSCI through which the inter-relationship between different operations in the context of a particular operational scenario. The stateless message exchange specification in a WSDL file is thus augmented with message choreography and stateful message exchange. Extensibility feature of WSCI suggests using RDF to annotate a WSCI interface definition with additional semantics.
Web Services Conversation Language allows defining the external visible behavior of the services by specifying the business level conversations and public processes supported by a web services. The conversations are defined using XML syntax and the WSCL document also specifies XML documents that are exchanged as a part of conversation and the order in which they are exchanged. WSCL provides a minimal set of concepts necessary for specifying the conversations. The specification states that typically the conversation is provided from the perspective of the service provider, which can also be used to determine the conversation from the perspective of the user. Though the conversation is defined from the service provider's perspective it separates the conversational logic from the application logic or the implementation aspects of the service.