Sample Web Process and support of different standards to model the process
BPEL4WS
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
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.
BPSS
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
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.
WSCI
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.
WSCL
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.