Process Modeling: VPML, BPMN, ARIS
Posted by keremkosaner on 10 April 2008
3.1 VPML : Visual Process Modeling Language.
3.2 BPMN : The Business Process Modeling Notation (BPMN) is a standardized graphical notation for drawing business processes in a workflow. The primary goal of BPMN is to provide a standard notation that is readily understandable by all business stakeholders. These business stakeholders include the business analysts who create and refine the processes, the technical developers responsible for implementing the processes, and the business managers who monitor and manage the processes. Consequently BPMN is intended to serve as common language to bridge the communication gap that frequently occurs between business process design and implementation.
3.2.1 BPMN’S SCOPE:
BPMN will be constrained to support only the concepts of modeling that are applicable to business processes. This means that other types of modeling done by organizations for non-business purposes will be out of scope for BPMN. For example, the modeling of the following will not be a part of BPMN:
* Organizational structures
* Functional breakdowns
* Data models
3.2.2 ELEMENTS:
The modeling in BPMN is made by simple diagrams with a small set of graphical elements. It should make it easy for business users as well as developers to understand the flow and the process. The four basic categories of elements are as follows:
* Flow Objects
o Events
o Activities
o Gateways
* Connecting Objects
o Sequence Flow
o Message Flow
o Association
* Swimlanes
o Pool
o Lane
* Artifacts
o Data Objects
o Group
o Annotation
These four categories of elements give us the opportunity to make a simple diagram (BPD). It is also allowed in BPD to make your own type of a Flow Object or an Artifact to make the diagram more understandable. Many types of Diagrams can be created.
3.3 BPEL : is a language for specifying business process behavior based on Web Services. Processes in WS-BPEL export and import functionality by using Web Service interfaces exclusively. WS-BPEL provides a language for the specification of Executable and Abstract business processes. By doing so, it extends the Web Services interaction model and enables it to support business transactions. WS-BPEL defines an interoperable integration model that should facilitate the expansion of automated process integration in both the intra-corporate and the business-to-business spaces.
In addition to providing facilities to enable sending and receiving messages, the BPEL programming language also supports:
* A property-based message correlation mechanism
* XML and WSDL typed variables
* An extensible language plug-in model to allow writing expressions and queries in multiple languages: BPEL supports XPath 1.0 by default
* Structured-programming constructs including if-then-elseif-else, while, sequence (to enable executing commands in order) and flow (to enable executing commands in parallel)
* A scoping system to allow the encapsulation of logic with local variables, fault-handlers, compensation-handlers and event-handlers
* Serialized scopes to control concurrent access to variables
3.3.1 BPEL Design Goals
There were ten original design goals associated with BPEL:
1. Define business processes that interact with external entities through Web Service operations defined using WSDL 1.1, and that manifest themselves as Web services defined using WSDL 1.1. The interactions are “abstract” in the sense that the dependence is on portType definitions, not on port definitions.
2. Define business processes using an XML-based language. Do not define a graphical representation of processes or provide any particular design methodology for processes.
3. Define a set of Web service orchestration concepts that are meant to be used by both the external (abstract) and internal (executable) views of a business process. Such a business process defines the behavior of a single autonomous entity, typically operating in interaction with other similar peer entities. It is recognized that each usage pattern (i.e. abstract view and executable view) will require a few specialized extensions, but these extensions are to be kept to a minimum and tested against requirements such as import/export and conformance checking that link the two usage patterns.
4. Provide both hierarchical and graph-like control regimes, and allow their use to be blended as seamlessly as possible. This should reduce the fragmentation of the process modeling space.
5. Provide data manipulation functions for the simple manipulation of data needed to define process data and control flow.
6. Support an identification mechanism for process instances that allows the definition of instance identifiers at the application message level. Instance identifiers should be defined by partners and may change.
7. Support the implicit creation and termination of process instances as the basic lifecycle mechanism. Advanced lifecycle operations such as “suspend” and “resume” may be added in future releases for enhanced lifecycle management.
8. Define a long-running transaction model that is based on proven techniques like compensation actions and scoping to support failure recovery for parts of long-running business processes.
9. Use Web Services as the model for process decomposition and assembly.
10. Build on Web services standards (approved and proposed) as much as possible in a composable and modular manner.
BPEL is an Orchestration language, not a choreography language . The primary difference between orchestration and choreography is executability and control. An orchestration specifies an executable process that involves message exchanges with other systems, such that the message exchange sequences are controlled by the orchestration designer. A choreography specifies a protocol for peer-to-peer interactions, defining, e.g., the legal sequences of messages exchanged with the purpose of guaranteeing interoperability. Such a protocol is not directly executable, as it allows many different realizations (processes that comply with it). A choreography can be realized by writing an orchestration (e.g. in the form of a BPEL process) for each peer involved in it. The orchestration and the choreography distinctions are based on analogies: orchestration refers to the central control (by the conductor) of the behavior of a distributed system (the orchestra consisting of many players), while choreography refers to a distributed system (the dancing team) without centralized control.
