One important base technology used in the majority of integration projects consists of business process modeling tools. The modeling process is always done using graphical tools. The Trivadis Integration Architecture Blueprint envisages the usage of graphical tools that support a clearly defined modeling notation. A number of these notations are available. The most important are Event-Driven Process Chain (EPC), Business Process Modeling Notation (BPMN), and Business Process Execution Language (BPEL), which are all explained next:
The Event-driven Process Chain (EPC) is a model used to represent business processes in an organization, as part of business process modeling (Scheer, Werth 2005). The notation was developed as a part of the Architecture of Integrated Information Systems (ARIS) for modeling business processes, and is a central element of the ARIS concept (Scheer et al. 2006). An example of an EPC is shown in the following diagram:
EPCs represent work processes in graphical form using semi-formal modeling language with syntax rules. This allows business processes to be systematized and parallelized, which saves time and money. As decisions are made within the process on the basis of conditions and rules, logical operators are used in the EPC (AND, OR, EXCLUSIVE OR). In addition to these operators, the basic model of the Event-Driven Process Chain includes events and functions. Objects are joined together in directional diagrams with lines and arrows in a 1:1 mapping (with the exception of logical links). In a chain of this kind, events and functions are alternate objects. This means that they form an alternating sequence, which results in a diagram being created. An important feature of the EPC is the representation of the functions that make up a process in a chronological and logical sequence.
The Business Process Modeling Notation (BPMN) is an OMG standard (OMG 2008). It provides symbols that enable technical and IT specialists to model business processes and workflows (White 2004). A BPMN example is shown in the following diagram:
The BPMN is designed to represent business processes in graphical form. The BPMN standards document also defines the semantics, in other words, the meaning of the symbols, but it places less emphasis on this aspect and does not focus on formal definitions. BPMN diagrams are referred to as Business Process Diagrams (BPD), and are intended to provide support for experts who are representing or developing processes. The specification does not include a standardized format for storing and exchanging diagrams that are created using BPMN.
The BPMN standard defines how a BPMN diagram can be converted to BPEL, so that the processes described can be run by a software package. However, BPMN and BPEL are not able to express the same types of concepts.
Note
It is worth noting that BPMN models are generally underspecified, and lack some of the details required for execution.
The graphical elements of the BPMN can be broken down into:
- Flow objects: These are nodes in the business process diagram. Flow objects represent either an activity (a task to be completed), a gateway (decision point), or an event.
- Connecting objects: These are the links in the business process diagram. Connecting objects are either sequence flows, which link activities, gateways, and events, or message flows, which illustrate the movement of messages between different objects.
- Swimlanes: These are the objects used to represent participants and systems.
- Artifacts: Other elements such as data objects (the artifacts processed by a business process), groups (the option of creating groups to represent sub-processes), and annotations (comments) are referred to as artifacts.
The first versions of Business Process Execution Language (BPEL) and BPEL4WS for web services were developed by IBM, Microsoft, Siebel, BEA, SAP, and Oracle in 2002 (version 1.1 was issued in April 2003). XLANG (from Microsoft) and WSFL (from IBM) were integrated into BPEL (Andrews et al. 2003). The most recent version (version 2.0) was published in the form of a committee draft on January 31, 2007 (Alves et al. 2006).
BPEL allows a process to be described and represented. The description takes a graphical form and is created in a BPEL editor. However, other workflow modeling techniques can also be used. In contrast to the other methods, the modeled business process can directly generate the controls for the workflow engine (BPEL engine). BPEL enables various different services to be linked together to form a complete application.
BPEL distinguishes between two different types of business processes: business protocols and executable business processes. Business protocols are abstract process descriptions that act as interaction patterns for the executable business processes.
A BPEL process consists of a process interface and a process diagram. The process interface is formulated in WSDL, as every BPEL process is a web service. The process diagram defines the process flow (actions), the instancing method (correlation sets), the partners (partner link), and the fault management mechanisms (fault manager).
The process is structured using a combination of hierarchical blocks and diagrams. The blocks can be nested. In BPEL they take the form of structured activities, which are similar to the constructions of a structured programming language. One typical feature is the <switch> structured activity, which defines a conditional implementation. Structured activities control the flow of atomic activities and form the nodes of an execution tree. The atomic activities control the individual steps in a BPEL process, for example,<invoke> calls a web service.
Almost every integration project needs business processes and other workflows to be modeled. A service-oriented integration would be almost impossible without the use of BPEL. Data integrations are usually accompanied by modeling of Extract, Transform, and Load (ETL) processes. In addition, the majority of commercial ESB and middleware infrastructures use graphical tools to model the routing of messages, or have their own process modeling tools. This means that it is advisable for every integration architect to be familiar with the use of these tools. Currently, the most important process modeling notation is BPEL.