Establishing a Standard Business Process Execution Architecture for
Integrating Web Services
Thilina Gunasinghe
Tim Kelly
Virtusa (Pvt) Ltd.
69, Alexandra Place
Colombo 7, Sri Lanka
tgunasinghe@virusa.com
Department of Computer Science
University of York
YO10 5DD, England
tim.kelly@cs.york.ac.uk
Abstract
With the realisation of the potential benefits of business process automation, many standards, best practices and technologies have evolved to model and execute business processes. The emerging web services technology provides great flexibility for the development of cross platform, service oriented applications. This paper addresses the utilisation of the web services technology for business process enactment and discusses a standardised architecture for web service based business process execution. As a key objective it highlights the need for standardisation in web service based business processes execution. In elaborating on the above need, this paper defines the development of a standard architecture to address key concerns such as service invocation, integration, transaction management, security and resource management in using the web services technology for business process execution.
1.
Introduction
In the accomplishment of successful business process automation, the nature and the underlying principles of a business process have to be well understood [1]. It is also important to evaluate the suitability and strengths of a potential execution environment, such as the web service technology, in fulfilling the objectives and principles of business process execution. In addressing the above needs, an architecture can be defined for the development of a standardised framework for using the web services technology for execution of business processes.
Business process modelling and analysis are viewed as key activities in understanding the principles of business processes such as long running activity interactions, state management and parallel execution
flows. A business process execution engine provides the execution environment and the infrastructure for business process execution. Typically, an enactment system should provide mechanisms such as activity coordination, resource management, parallel constraint management, transaction management, security and state management when executing a business process model [2], [3].
The web services technology provides an infrastructure for standardised interoperability between heterogeneous application environments [4]. However, the formation of new applications through the integration of web services would depend on many integration challenges such as transaction management, activity coordination and security management. Therefore, these challenges must be addressed in using the web services technology for business process execution.
Addressing the principles of business processes and the integration challenges of web services, this paper defines a standardised architecture for web service based business process execution.
2.
Background
Many industrially accepted business process representation standards such as Role Activity Diagrams [5] and Business Process Modelling Notation [6] provide a series of effective business process modelling and analysis techniques. These standards provide mechanisms for understanding the nature and capturing the functionality of a business process. With regard to business process enactment, paradigms such as the Workflow Management Coalition’s Workflow Reference Model [7] provide essential standards for business process execution engines. Malone and Crowston [2] have also identified activities such as managing shared resources and managing simultaneous constraints as important
aspects in coordinating business process activities in an execution environment. Aalst et al [8] identifies business process patterns such as parallel split and synchronisation to document executable behaviour of a business process management system. These patterns specify the basic functional and behavioural requirements of an execution architecture.
The W3C provides the architecture of web services through the Web Services Architecture Specification [4]. This specification defines the key technologies such as SOAP and WSDL that are essential for web service based application development. The WS-Coordination [9] and WS-Transaction [10] specifications provide evolving but extensive models for coordination and management of transactions in integrating web service based applications. These specifications also define transaction management schemes for services that require long running interactions. The WS-Security [11] specification defines token based authorisation, message integrity and confidentiality based security measures. However, it is evident that, many sub specifications of the web services security framework are yet to be completed.
Web service based business process execution languages could be considered as the most important piece of existing work that is relevant in defining an architecture for web service based business process execution. These languages provide the syntax and semantics of defining an executable business process using the web services technology. At the time of writing, standard languages such as the Business Process Execution Language for Web Service (BPEL4WS) [12] and the Business Process Modelling Language (BPML) [13] existed. Both these languages provide facilities to define process partners, activities, control flow of the process and fault handling functionalities of the process.
Presently a handful of web service based execution-engines such as BPWS4J [14] and ChoreoServer [15] that conform to the BPEL4WS specification exist in the industry. However, a standard architecture with coverage of web service based business process execution functions such as service invocation, integration, transaction management, security and resource management is yet to be developed.
3.
Architectural Drivers
The architectural drivers of a system combine the most important quality and functional requirements that are used in determining the architecture of the system [16]. The architectural drivers of a web service based business process execution architecture should cover both business process execution principles and web service integration and coordination challenges.
The investigation of the functional and quality attribute based requirements for a Business Process Execution Architecture for Web Services (hereafter referred to as BPEAWS), led to the discovery and prioritisation of the following architectural drivers:
• Driver 1: BPEAWS shall provide an efficient business process interpretation and execution mechanism. BPEAWS should have an efficient framework to execute business processes. Such a framework is important to optimise the performance of a business process execution engine. (Rank: 2)
• Driver 2: BPEAWS shall provide efficient long running business interactions that are tolerant to component failures. Managing the state of interactions and transactions among the participants of a business process is essential to its successful completion. Such long running interactions should also survive component failures and be optimal in terms of resource usage. (Rank: 1)
• Driver 3: BPEAWS shall support a variety of partner service invocation mechanisms such as RPC or asynchronous message based service invocations. A standardised framework should have the facility of supporting the seamless addition of many newer participant invocation mechanisms. (Rank: 2)
• Driver 4: BPEAWS shall secure the interactions between the participant services of the business process. BPEAWS should provide a security model to safeguard the interactions between the participant services. Such a security model is necessary for the safeguarding the integrity and confidentiality of critical business transactions. (Rank: 2)
• Driver 5: BPEAWS shall provide an extensible interface for the invocation of business processes. The business processes that are deployed in BPEAWS should have the facility of being invoked by many interfaces. BPEAWS should define a standard for different varieties of invocation interfaces. (Rank: 3)
• Driver 6: BPEAWS shall provide a usable technical interface for the deployment and administration of business processes. This driver specifies the importance of having a management interface for the deployment and maintenance of business processes in BPEAWS. (Rank: 4)
The above drivers are used as key goals in the derivation of BPEAWS.
4.
The Architecture
As evident through the above architectural drivers, attributes such as modifiability, performance, transaction management and security are vital in defining a standardised web service based business
process execution architecture. As an initial framework of satisfying the above attributes, BPEAWS is defined with layers for the Service Interface, Execution, Base Services and Communication.
The Service Interface layer provides an entry point for the invocation and activation of business processes. The Execution layer is responsible for the execution of the business process. Thus, this layer holds performance oriented modules for performance critical functions, infrastructure management modules to load processes and to coordinate the other architectural modules and flow control modules to control the flow of execution of business processes. The Communication Layer represents the external service invocation and communication functionalities. Finally, the Base Services represent the common infrastructure services of BPEAWS such as security and transaction management.
As depicted in Figure 1, the service interface layer hosts the listener and message router modules. The listener module provides business process invocation listeners that are used for the invocation / activation of business processes. This module strengthens extensibility of the listener interface by facilitating the seamless addition of many listener types through the implementation of a general interface. The message router module is invoked by the listener module, when it receives a process invocation request. This module abstracts the invocation / activation dispatching mechanism by effectively dispatching requests to the Execution Layer.
The Execution layer hosts the container, process model, flow control and execution modules. The container module is responsible for receiving process execution messages and for the provision of the infrastructure services to communicate with the base services and communication layers. This module loads the appropriate process through the process model module and initiates a flow control instance to track the state of the process. The container will also be used by the execution module to access the base services and to transmit messages to the communication layer. The provision of infrastructure management functions by the container, abstracts the rest of the modules from the details of the processing environment. The container also acts as a virtual interpreter by maintaining standard protocols to communicate with the base services and communication layers. Hence, the container brings rich levels of modifiability and portability to BPEAWS.
The process model module hosts the deployed executable business processes of BPEAWS that conforms to an industrial web service based business process execution language such as BPEL4WS. This module optimises the performance and scalability of
BPEAWS by holding an executable, cached version of the business process. The flow control module is responsible for the management of state and detection of business exceptions in a business process instance. As a performance optimisation measure this module is also responsible for initiating the activation and deactivation of business processes. At the detection of a business exception, the module initiates the appropriate recovery or compensation actions to maintain the consistency and integrity of the business process. The safeguarding of integrity and consistency of the business process will facilitate towards richer levels of reliability.
The execution module is primarily responsible for the execution of the business process. The module executes processes by interpreting them and evaluating their execution conditions. Every activity of the process model will be evaluated and the ones that satisfy the business rules of the process would be executed. This module is optimised to implement a performance oriented multi-threaded execution model. The module utilises the container to access the base services and the communication layers.
The Communication layer hosts the adapter and connection manager modules. The adapter module is an extensible generalised module with a series of different adapters such as RPC and asynchronous adapters that are used to communicate with the participant web services of the business processes. The generalisation of this module facilitates extendibility through the addition of newer adapters by implementing a general adapter interface. The connection manager module provides an abstract interface for the execution layer to communicate with the participant services of the business process. This module hides the implementation details of the communication adapters and improves scalability through caching of partner connections.
The base services layer hosts security, transaction management, activation, deployment, language meta-model, administration and utility modules. The security module provides the security framework of BPEAWS. It provides mechanisms for authentication, authorisation and communication message security. This module should be designed with adherence to a web service security standard such as the WS-Security framework [11]. Finally, this module facilitates the seamless addition or modification of security protocols / mechanisms.
The transaction management module provides the transaction management framework of BPEAWS. The transaction management framework is accessed by the container to provide consistency and integrity to the business processes.
Figure 1 – Architectural Module View It mainly provides mechanisms for transaction
commitment, rollbacks and compensation. This module is designed to be compatible with a generalised framework such as the WS-Transaction framework [10] for transaction management and thereby facilitate standardised web service transaction management. The activation module provides the activation and deactivation model of BPEAWS. The flow control module uses this module through the container to deactivate business processes when they are required to wait for a long-running business decision.
With the receipt of an activation message the process is reactivated by this module. The activation and deactivation process contributes to the overall performance and scalability of BPEAWS by efficient memory, processor and resource management.
The deployment module provides the process deployment service. The deployment module utilises the constructs of the language meta-model module for the deployment of the process. The generalisation of the deployment module allows the seamless incorporation of newer deployment features to the system. The language meta-model module represents the business process definition language of BPEAWS. The language meta model of BPEAWS should be made compatible with a industrially accepted process definition language such as the BPEL4WS [12] specification. At deployment, the constructs of the process definition language are used to instantiate an executable process model for the deployed business process. Through the provision of construct modifiability, the language meta-model module facilitates modifiability and replacement of different
process definition languages without an impact to the rest of the system.
The administration module provides the administrative and management services of BPEAWS. This module is defined as a general module and is anticipated to be extended to monitor and control the instances of business processes. The utilities module provides the utility functions of BPEAWS. This module provides a common interface to access the utility components such as audit trails, output / input transformations. This module is also expected to be extensible to provide a richer range of utility functions.
5.
Generalised Design of the Container
Module
As mentioned under its architectural description, the Container Module is responsible for the coordination of the other modules in executing a business process. Therefore, the design of the container module utilises the Command Design Pattern [17] in generalising the module to make it easily extendible.
As depicted in Figure 2, the collaboration between the other modules such as Flow Control, Execution and the modules of the Base Services Layer is carried through driver classes. For example, when the execution module requires communicating with a partner web service, it constructs a Communication Message object. The container receives this request through the execution driver and passes it to the communication layer through the respective communication driver.
Figure 2 – Generalised Design of the Container Module The communication layer then interprets the
communication message, communicates with the partner web service and sends the response (another communication message) back to the container via the communication driver’s call-back port. The response is then transmitted back to the execution module via the execution driver. Likewise all requests / responses that flow through the container adhere to the above pattern
The command pattern clearly separates the creators of the command objects from the consumers of the command objects [17]. For example, the execution module does not require the knowledge of the existence of the communication layer. Simply the execution module is totally unaware of the communication handling functionality of the communication layer. This framework allows the addition of new functionality to the container module by simply creating a driver and the respective command objects. The extensions or modifications would be transparent to the other modules that depend on the container. Furthermore, portability is strengthened by the driver mechanism of the container. In an event of porting the engine to a different environment, the drivers could be changed to the settings of that environment and in effect keep the rest of the components unchanged.
6.
Standardised Transaction Management
The second architectural driver of BPEAWS focuses on the need of supporting long running business process interactions that are tolerant to component failures. In order to assure the integrity and consistency of these business interactions, a transaction management system must be employed. An effective transaction management technique would provide transaction commitment, rollback and abortion facilities. The transaction management framework of BPEAWS is designed to be compliant with the
WS-Coordination [9] and WS-Transaction framework [10]. These frameworks provide comprehensive means of interaction management for integrated web services.
As depicted in Figure 3, the Transaction Manager provides a façade for the transaction framework. As required by the WS-Coordination framework [9], Transaction Activation and Transaction Registration classes provide the activation and registration services of the framework. The transaction activation class creates a transaction context object, which is used by the participants of the transaction to register for the transaction. After the completion of the registration phase, the transaction is initiated by calling the notifyStart method of the Transaction. At execution the executor will use the Transaction Context to register participants and activate the transaction. Any action to the transaction such as a start, commit, rollback or abort is handled by the local transaction and is also communicated to the respective Transaction Manager via the processEvent method.
The Transaction Manager uses the Transaction Services to issue a respective start, commit, rollback or abort action to the participants that are registered in the transaction context. In this way a failure of a transaction could be easily communicated to the participating transaction managers of the respective web services to initiate recovery procedures. This strategy assures the effective management of state and handling of transactions.
7.
Implementation
A reference implementation of BPEAWS was implemented using the BEA WebLogic J2EE container [18] with full compliance to the BPEL4WS specification [12]. The components of BPEAWS were mapped to the respective J2EE [19] artefacts in the following manner:
Figure 3 – Standardised Transaction Management
• The EJB Container – The respective modules of BPEAWS is deployed as Session Beans, Message Beans and standard classes under the context of the EJB Container. The EJB container provides object brokering, state management and server side services for the execution of BPEAWS
• The Web Container – the administrative and deployment functions of BPEAWS are provided as a J2EE web application that runs in the Web Container of the J2EE Server. The web container provides web hosting, request-response mapping, external resource access and session management facilities for BPEAWS.
• J2EE Services [19] – Java Naming and Directory Interface (JNDI), Java Message Service (JMS), Java Web Services and Java XML Processing services are used for the implementation of BPEAWS.
The evolving nature of the Web Services stack of technologies had a considerable impact on the implementation. For example, due to the lack of a mature implementation of the WS-Transaction framework [10] at the time of development, the core distributed transaction framework of BPEAWS had to be developed from ground-up, incorporating the basic features of transaction management. Also the development of state management and process activation / deactivation mechanisms were challenging. The state of each business process needed to be monitored and deactivated / activated efficiently maximising the usage of resources in an optimal manner.
The reference implementation of BPEAWS is fully functional and it provides a working proof of concept of the above architecture for web service based business process execution.
8.
Achieving Architectural Qualities
The following sections elaborate the achievement of architectural qualities through the architecture and design of BPEAWS:
Modifiability
Modifiability is an important concern in standardisation. The layered architectural style was selected to provide layer modifiability to BPEAWS. At the module level, the design of the listener and adapter modules provide the flexibility of adding new service invocation and partner communication mechanisms respectively through generalised listener and connection interfaces. Also, as mentioned under the design of the container module, its driver mechanism provides extensive levels of modifiability to the base services of the system. The drivers allow seamless addition of new services or modifications to existing services. For example, the security base service could be changed without an impact to its consumers. Finally, the language meta model module and the process model module make the business process definition language modifiable. For example, the business process language of the engine could be changed by simply changing the implementation of these two modules.
Performance
Primarily, performance is optimised through the execution module. This module provides a multi threaded execution engine that implements the Observer Pattern [17] for event based process activation and deactivation. The multi threaded execution engine facilitates the parallel execution of many processes and process activities. The event based activation and deactivation mechanism provides an efficient and scalable solution for the long running business processes by deactivating them when they are
not required to be active. Furthermore, where applicable, object caching is used for performance optimisation. The process model module and the adapter module respectively provides cached instances of the business processes and connections to partner services to eliminate the object loading and initialisation costs. Collectively the above measures improve the runtime performance and scalability of the process execution environment.
Security
The architecture delegates the handling of security to the security module. Architecturally, this module presents the security framework of BPEAWS. This module is designed to adhere to the WS-Security framework [11]. The module is designed to implement encryption based message security and token based authentication schemes of this specification. Message encryption and decryption is used to safeguard the confidentiality and integrity of the business process information. The Token based authentication scheme restricts unauthorised access to the business processes. These services of the security framework are provided to the rest of the system through the façade Security Manager class of the security module. The security module should be further improved with the finalisation of specifications such as WS-SecureConversation [20] and WS-Federation [21]. Availability
The architecture facilitates availability through a componentisation framework. The architectural modules of BPEAWS could be easily mapped to the respective artefacts of an implementation technology such as the Sun’s Java 2 Enterprise Edition (J2EE) [19] or Microsoft’s .Net Framework [22]. These implementation technologies provide comprehensive architectures for component clustering and fail over management. Due to the high complexity of designing and developing its own availability mechanism, the architecture of BPEAWS utilises availability assurance techniques of a commercial implementation platform. Portability
Portability is supported at two distinct levels. The design of the container module facilitates portability by its driver mechanism. As described in the design of the container module the communication between modules flows through the drivers of the container. Therefore, BPEAWS could be easily ported into a different environment by changing the drivers of the container to adapt to the settings of the new environment. For example, if the new environment has a different communication module the rest of the system could be seamlessly integrated into the new communication
module by changing the drivers of the container. Modules such as the adapter and listener also strengthen portability of BPEAWS by allowing the integration of newer Connection, Listener components without an impact to the rest of the system. BPEAWS also benefits from the portability levels that are offered by its implementation platform. For example, due to the portability levels offered by the J2EE environment, an implementation of BPEAWS could be deployed in any J2EE compliant application server. This improves the portability of the process execution environment.
9.
Conclusions
The web services technology holds great potential for dynamic composition and execution of business processes. However, issues such as long running business interactions, transaction management, security and resource management are important in using the web services technology for business process execution. More specifically an architectural framework is important to standardise the means of using the web services technology in executing business processes. This paper identifies the key elements and principles that are required for web service based business process execution. It provides an architectural view of the modules that are required and their respective responsibilities in standardising web service based business process execution.
The paper has also highlighted that, qualities such as modifiability, security, performance and availability are key requirements in integrating web services for the composition of business processes. It also positions web service standards such as Coordination, WS-Transactions and WS-Security in the developed execution architecture.
Finally, it is anticipated that many business organisations would invest in a business process execution architecture and rely on other organisations that professionally develop web service based business process activities, to dynamically create their own customised business processes. Service agreements are likely to be signed between the consumers and producers of these services to cover the costs of using these services and the provision of the Quality of Service levels. The architecture produced through this paper would facilitate such future avenues by the provision of a framework for service based business process execution.
References
[1] Martyn A. Ould, Business Processes Modelling and Analysis for Re-engineering and Improvement, Wiley, 1995
[2] Thomas W. Malone and Kevin Crowston; The Interdisciplinary Study of Coordination; ACM Computing Surveys; 1994
http://ccs.mit.edu/papers/CCSWP157.html#RTFToC6 [Accessed on 01.06.04]
[3] Gartner Inc; Composite Applications Head Toward the Mainstream; 2003
http://www4.gartner.com/resources/117900/117985/117985. pdf [Accessed on 02.06.04]
[4] David Booth, Hugo Haas, Francis McCabe, Eric
Newcomer, Michael Champion, Chris Ferris, David Orchard; Web Services Architecture; W3C;
http://www.w3.org/TR/ws-arch/ [Accessed on 06.06.04] [5] A. W. Holt, H. R. Ramsey, J. D. Grimes; Coordination System Technology as the Basis for a Programming Environment; ITT Technical Journal (Electrical Communication); 1983
[6] Business Process Modelling Notation ver 1.0; Business Process Modelling Initiative; 2004; http://www.bpmi.org [Accessed on 25.05.04]
[7] Workflow Management Coalition; The Workflow Reference Model; 1995
http://www.wfmc.org/standards/docs/tc003v11.pdf [Accessed on 29.05.04]
[8] W.M.P. van der Aalst, A.H.M. ter Hofstede2, B. Kiepuszewski3, and A.P. Barros; Workow Patterns; Department of Technology Management, Eindhoven University of Technology;
http://tmitwww.tm.tue.nl/research/patterns/download/wfs-pat-2002.pdf [Accessed on 05.06.04]
[9] Felipe Cabrera, George Copeland, Tom Freund, Johannes Klein, David Langworthy, David Orchard, John Shewchuk, Tony Storey; Web Services Coordination
(WS-Coordination); BEA Systems, International Business Machines Corporation, Microsoft Corporation; 2002; ftp://www6.software.ibm.com/software/developer/library/ws-coordination.pdf [Accessed on 16.06.04]
[10] Felipe Cabrera, George Copeland, Bill Cox, Tom Freund, Johannes Klein, Tony Storey, Satish Thatte; Web Services Transaction (WS-Transaction); BEA Systems, International Business Machines Corporation, Microsoft Corporation; 2002;
http://www.ibm.com/developerworks/library/ws-transpec/ [Accessed on 16.06.04]
[11] International Business Machines Corporation, Microsoft Corporation, VeriSign, Inc.; Web Services Security (WS-Security) Version 1.0 05; 2002
http://www-106.ibm.com/developerworks/webservices/library/ws-secure/ [Accessed on 17.06.04]
[12] Tony Andrews, Francisco Curbera, Hitesh Dholakia, Yaron Goland, Johannes Klein, Frank Leymann, Kevin Liu, Dieter Roller, Doug Smith, Satish Thatte, Ivana Trickovic, Sanjiva Weerawarana; Business Process Execution Language for Web Services version 1.1 (Public Draft); BEA, IBM, Microsoft, SAP AG and Siebel Systems, 2003
http://www106.ibm.com/developerworks/webservices/library /ws-bpel/ [Accessed on 27.05.04]
[13] Business Process Management Initiative; Business Process Modelling Language; 2002; http://www.bpmi.org/ [Accessed on 21.06.04]
[14] IBM; Business Process Execution Language for Web Services Java TM Run Time; 2002;
http://alphaworks.ibm.com/tech/bpws4j [Accessed on 22.06.04]
[15] OpenStorm, Inc; Service Orchestrator Product Data Sheet;
http://www.openstorm.com/articles/ServiceOrchestrator.pdf [Accessed on 23.06.04]
[16] Len Bass, Paul Clements, Rick Kazman; Software Architecture in Practice, Second Edition; Addison Wesley, 2003
[17] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides; Design Patterns, Elements of Reusable Object Oriented Software; Pearson Education; 1995
[18] BEA Systems Inc. WebLogic Server 7.0 Documentation;
http://edocs.bea.com/wls/docs70/ [Accessed on 17.08.04] [19] Sun Microsystems Inc; Java 2 Enterprise Edition; 1994 – 2004; http://java.sun.com/j2ee/ [Accessed on 05.08.04] [20] BEA Systems, Inc., Computer Associates International, Inc., International Business Machines Corporation, Layer 7 Technologies, Microsoft Corporation, Netegrity, Inc., Oblix Inc., OpenNetwork Technologies Inc., Ping Identity Corporation, Reactivity Inc., RSA Security Inc., VeriSign Inc., and Westbridge Technology, Inc.; Web Services Secure Conversation Language (WS-SecureConversation) Version 1.1; 2001-2004;
http://www-106.ibm.com/developerworks/library/specification/ws-secon/ [Accessed on 07.08.2004]
[21] IBM Corporation, Microsoft Corporation, BEA Systems, Inc., RSA Security, Inc., Verisign, Inc.; Web Services Federation Language (WS-Federation); 2001-2003;
http://www-106.ibm.com/developerworks/webservices/library/ws-fed/ [Accessed on 10.08.2004]
[22] Microsoft Corporation; .Net Framework; 2004; http://msdn.microsoft.com/netframework/ [Accessed on 15.08.04]
