Business Process Enactment
In this chapter, we discuss the business process enactment environment of the CrossWork architecture, providing support for network business process enactment and legacy system integration. We first discuss the overall approach to enactment, which consist
- PDF / 652,635 Bytes
- 20 Pages / 439.37 x 666.142 pts Page_size
- 38 Downloads / 195 Views
Business Process Enactment Georgios Kouvas, Paul Grefen, and Ana Juan
In this chapter, we discuss the business process enactment environment of the CrossWork architecture, providing support for network business process enactment and legacy system integration. We first discuss the overall approach to enactment, which consists of global enactment and local enactment, supported by two modules as described in the architecture design (see Chapter 5). Details of the Global Enactment module are discussed in Section 8.2. The discussion of the Local Enactment module follows in Section 8.3. As described in the architecture, enactment is coupled to Legacy Integration. In Section 8.4, we therefore discuss the Legacy Integration module. We conclude this chapter in Section 8.5.
8.1 Overall Approach to Enactment After a Business Network Process has been composed and verified, it is ready for enactment by an IVE. Enactment of a Business Network Process is based on a two-level mechanism, consisting of global process orchestration and local process execution. Both levels are designed such that they allow flexible enactment topologies through the use of remote workflow clients [6]. To assure interoperability with industry-standard process enactment platforms, the industry-standard Business Process Execution Language (BPEL) [2] is used for enactment. BPEL is an XML-based language, built on top of SOA and Web Services specifications. It is used to define and manage long-lived service orchestrations or processes. In BPEL, a business process is a large-grained Web Service, which executes a control flow to complete a business goal. The steps in this control flow execute activities that are centred on invoking partner services to perform tasks and return results to the process. The drivers for choosing BPEL in our approach are manifold. Firstly, enterprises are evolving their SOA implementations from simple, fine-grained services, to more complex, large-grained services. Secondly, enterprises are employing service-oriented architecture strategies for integration. G. Kouvas (B) Exodus, Athens, Greece e-mail: [email protected] N. Mehandjiev, P. Grefen (eds.), Dynamic Business Process Formation for Instant Virtual Enterprises, Advanced Information and Knowledge Processing, C Springer-Verlag London Limited 2010 DOI 10.1007/978-1-84882-691-5_8,
113
114
G. Kouvas et al.
Thirdly, in response to the first two items, vendors are creating integration and SOA infrastructure solutions that offer BPEL orchestration, and/or use BPEL for internal processing. Finally, the specification is maturing; BPEL 2.0, sponsored by the Organization for the Advancement of Structured Information Standards (OASIS), is now available. Figure 8.1 depicts the CrossWork enactment architecture. The two levels of workflow enactment (global enactment and local enactment) are clearly identified in the enactment architecture. Next to this, we employ a monitoring user interface module. Fig. 8.1 Enactment architecture
Monitor UI BNP spec exception
BPEL engine
monitor & co
Data Loading...
