Flexible Support of Inter-Organizational Business Processes Using Web Services Rainer Schmidt Department of Computer Science University of Applied Sciences Beethovenstraße 1 73430 Aalen
[email protected]
Abstract. Inter-organizational business processes which cross multiple organizations need new kinds of flexibility which are not properly supported by existing enactment architectures. Therefore, after analyzing these requirements, a new enactment architecture based on web services is developed. It uses a homogeneous and dynamic composition of so called aspect-element-oriented web services to support inter-organizational business processes.
1. Introduction Today, enterprises must be able to quickly establish partnerships with other enterprises to combine their competencies. The set of enterprises participating in the business processes may change rapidly: there is a high fluctuation of partners. This permanent building and dismantling of partnerships is the key feature of interorganizational business processes and necessitate new kinds of flexibility. To create an enactment architecture which supports inter-organizational business processes and their new flexibility requirements, this paper proceeds as follows. In section 2, new kinds of flexibility necessary for the enactment of inter-organizational business processes are analyzed; in section 3 further requirements for the enactment of interorganizational business processes are identified. In Section 4, the enactment architecture, the so-called aspect-element-oriented schema representation is designed. It is implemented in Section 5 as a so-called composite application, using web services. Section 6 is dedicated to the evaluation of related research.
2. New kinds of flexibility in inter-organizational business processes New kinds of flexibility are necessary to support inter-organizational business processes, which either augment or extend the flexibility needed for the support of intra-organizational business processes.
2
Rainer Schmidt
• Business process evolution The enactment of inter-organizational business processes is subject to more changes than the one of intra-organizational business processes. There are more sources for change requests compared to an isolated environment. But more important, the changes differ in extent. Changes of the business process model, the so-called business process evolution, imply the introduction of new modeling elements or rules. They may also imply the integration of new services. On the business process schema layer, the “real” business process is formalized as business process schema (or schema for short) using the elements and rules of the business process model. The schema contains an abstract view of the business process. It defines allowed paths for the execution of the business process.The schema defines the sequence of activities to be executed in the business process and rules for executing activities dependent on preconditions. For example, the schema of an order processing defines the activities to be performed to process the order and rules like “Reject the order if the ordered product is out of production”. The requirement to implement changes on the business process schema layer is called (business process) schema evolution. A typical example of schema evolution is the rearrangement of activities such as executing two activities in parallel which were performed sequentially before. On the third layer, the business process instance layer, the process schema is used as template for creating business process instances. Business process instances (or instances for short) represent the concrete processing of an order, e.g. the processing of order number 4711. Instance evolution means, that the execution of one or more instances shall deviate from the execution originally specified in the business process schema. • Service extensibility and integration Above, business process evolution has been identified as an important requirement. Business process evolution implies that the set of services necessary to execute activities has to be extensible: New services have to be integrated due to changes to the activities. Therefore, an architecture for the enactment of inter-organizational business processes must be capable of integrating new and services not known before. The services may be highly distributed and heterogeneous because different organizations use different infrastructures. • Asynchronous service evolution When enacting business processes across organizations, the underlying services may evolve asynchronously. There is no orchestrated evolution of services, because there is no central authority which could control evolution.
3. Further requirements for the enactment of inter-organizational business processes • Enactment autonomy is defined as the capability to autonomously enact business processes. As participating organizations of inter-organizational business processes change quickly, all participants must be able to leave the partnership without
Flexible Support of Inter-Organizational Business Processes Using Web Services
3
loosing the capability to enact their business processes and they must be able to integrate quickly into a new partnership. • Knowledge encapsulation is necessary to protect the knowledge about business processes tailored to business needs, which is a decisive competitive factor. Due to the short lifetime of partnerships, the knowledge about business process design has to be kept secret from partners, which may soon participate in competing partnerships. • In order to react to market changes it must be possible to quickly fulfill an increased demand of products. Therefore an enactment architecture for interorganizational business processes must be highly scalable. • Service autarchy is necessary to cope with business partner fluctuation typical for the enactment of inter-organizational business processes. Only if it is possible to quickly change the provider of a service, a quick adaptation to changing partners is possible.
4. The Aspect-element-oriented schema representation Two basic architectures for business process enactment can be identified as shown in Fig. 1. They are called the direct and the indirect enactment architecture and differ in the amount of flexibility support. Business process schema Activity
Business process schema Generation (1)
Schema representation Engine
Interpretation
s1
Schema representation
enactment
enactment
System boundary
Schema representation enactment
(2)
s2
s1
Direct enactment
s2
Indirect enactment
Fig. 1. Direct and Indirect enactment
In the direct enactment architecture business processes are enacted by a mechanism interpreting the business process schemata. Changes to business process schemas or instances can be implemented immediately because the schema is interpreted. On the other side, model evolution is not supported, because the interpretation engine has to be changed. The interpretation impedes service extensibility and integration, as the centralized enactment mechanism is not able to integrate new and formerly unknown services. Furthermore a centralized interpretation mechanisms is not able to cope with asynchronous, that means decentralized service evolution.
4
Rainer Schmidt
The scalability of the direct enactment architecture is rather limited as the interpretation is centralized and cannot be distributed. Because every step in the enactment of business processes requires the involvement of the enactment mechanism, a central bottleneck is created. Furthermore, the existence of a centralized enactment mechanism destroys the enactment autonomy and knowledge encapsulation as business process definitions are centralized and therefore not under control of the business process owner. Service autarchy is lost too, because the centralized enactment mechanism integrates all services used during business process enactment. The other basic architecture is called indirect enactment. Here, enactment is done in two steps. In the first step, a so called schema representation is created. In the second step, the schema representation enacts the business process. Thus the enactment of business processes can be separated from the creation of the schema representation. The indirect enactment architecture offers only a limited flexibility for schema changes, because, the schema representation is monolithic and static. Service extensibility and integration are impeded because the schema representation is monolithic and the integration capabilities limited, the same applies for the asynchronous service evolution. Enactment autonomy and knowledge encapsulation can be achieved at least by workarounds such as partitioning the schema representation. The result of our investigations shows, that neither the direct nor the indirect enactment architecture fulfils all requirements for the enactment of interorganizational business processes. Therefore two different potential strategies exist. One strategy is to improve of the direct enactment architecture. However, there are requirements that cannot be met by this architecture such as enactment autonomy and knowledge encapsulation. The other strategy is to improve the schema representation of the indirect enactment architecture in order to support business process evolution. To do so, the former monolithic schema representation has to be split up into schema elements with an appropriate granularity. First ideas concerning an appropriate service granularity for business process enactment can be found in [AWBB93] and [LeRo97]. An analysis why objectoriented software systems in general may become inflexible is the basis of AspectOriented-Programming (AOP) [Kicz96]: Therefore, when designing a schema representation, the aspects of the business process have to be identified and separated. Five basic aspects of business processes are identified in [JaBu96]: the functional, control, informational, organisational and operational aspect. These “core-aspects” are orthogonal dimensions of business processes. An appropriate granularity can be achieved using aspect elements. Aspect elements are no further dividable, atomic parts of business processes which contain only functionality of one aspect. If aspect elements are applied as granularity for a schema representation, a so-called aspectelement oriented schema representation is created. Furthermore, it has to be decided whether a homogeneous or heterogeneous composition should be chosen. A heterogeneous composition means that one group of aspect elements plays an emphasized role. The problem of heterogeneous composition is that the emphasized aspect elements violate service autarchy by creating “hubs” for accessing the services used for implementing other aspect elements. Contrary to heterogeneous service composition, the homogeneous service composition maintains
Flexible Support of Inter-Organizational Business Processes Using Web Services
5
the service autarchy. There are no aspect elements which are needed to access other aspect elements: all services are accessed directly. The homogeneous composition has two kinds of connections between aspect elements. Temporal connections indicate that the aspect elements are executed consecutively. Client-server connections indicate the (multiple) use of an element by another element. To visualize the concept of the homogeneous aspect element oriented schema representation, a small fragment is represented in Fig. 2. The fragment defines, that starting from a calculated order value of 5000 Euro, an extended check of the customer’s credibility by querying an (external) rating system shall take place. Otherwise a standard check is done by the accounting department. The representation elements are coloured according to the aspect they belong to. The full lines indicate temporal connections. The dashed lines indicate client-server relationships. Operational aspect Temporal connection Informational aspect
Rating system (external)
Organisational aspect Client/server connection
Control aspect
Calculate order value
Continue order processing
Extended check
Order Value > 5000 Euro
Credibility Ok ?
Standard check
Reject order
Order management system Accounting department
Fig. 2. Homogenous, aspect-element-oriented schema representation
5. Implementing the aspect element oriented schema representation by composite applications It can be easily seen, that the elements of the schema representation must be connected in a reconfigurable manner, so that extensions and changes to the schema representation can be implemented dynamically. This is achieved by so-called composite applications on the basis of web services. Composite applications using web services break with the thinking that applications and executables have to be one. There is no “executable” any more which contains the application functionality. A composite application is created by a set of interconnected and parameterized web services as shown in Fig. 3 Web Services [W3WS] provide the universal and transparent access to asynchronously evolving services in heterogeneous environments by using near ubiquitous internet technologies such as HTTP [W3C] and XML [XML]. The use of web services as implementation base helps to fulfill some of the requirements for the enactment of inter-organizational business processes identified above. Service
6
Rainer Schmidt
autarchy is fulfilled by web services, because they provide universal access to services. They also fulfill the requirement of service extensibility and integration because they allow to transparently integrating services across heterogeneous platforms. Furthermore discovery mechanisms such as UDDI allow to integrate up to then unknown services and extend the set of available services. Different versions of a web service can be differentiated by different name spaces. Therefore web services fulfill also the requirement of asynchronous evolution of services. The adaptation of web services to an individual composite application is done by applying specialization information to the services: the web service is parameterized and connected to other web services depending on the requirements of the composite application. Therefore, the specialization information contains both parameterization and connection information. The parameterization information adapts the web service to the individual needs of the composite application. The connection information contains the connections of the web service with other services in the context of the composite application. For different composite applications there is different specialization information. The specialization information is not centrally stored but directly accessible to the web services. The specialization information for different composite applications is discriminated by the so-called global context identifier. The so-called local context identifier differentiates multiple uses of the same service in a composite application. Therefore, every web service “knows” what to do every time. An example is given in Fig 3. There are two composite applications A and B. They are created using three web services s1, s2 and s3. Composite application A
Composite application B
Service
s1
s2 ia1
s2 ia1
s3 ib1
ib1 Specialization information
s3 ib2
s1
ia1
s2
ia1 ib1
s3
ib1
Specialized service
ib2
Fig. 3. Composite application
Composite application A is created by using web services s1 and s2 with the specialization information denoted with the context identifier ia1. The identifier is composed from a global and a local context identifier. The global context identifier ia associates the specialization information with the composite application A. The local context identifier denoted “1 “ determines the context within composite application A. The specialization of s1 contains the connection information representing the connection between s1 and s2. Furthermore s1 and s2 are parameterized. Composite application B is created by using web services s2 and s3 using specialization information denoted with the global context identifier ib. By evaluation of the global context identifier, web service s2 can differentiate if it is called in the context of composite application A or composite application B. Web service s3 is multiply used within composite application B. There are two sets of specialization information
Flexible Support of Inter-Organizational Business Processes Using Web Services
7
denoted with the global identifier ib and differentiated by the local identifiers “1 “ and “2 “ . If s3 is used for the first time, the specialization information denoted with ib1 is used. The second time, the specialization information ib2 is used. The execution of aspect element oriented composite applications is done by running iteratively through 4 phases. Each service runs through the phases after it has been initiated by its predecessor. The execution of the composite application stops when the final service is completed. The first phase is the initiation phase: The service is started using the information supplied from the calling service. In the second phase, the specialization phase, the service is tailored to the individual needs of the composite application. In the third phase, the execution phase, the service is executed using the parameterisation and connection information, which is contained in the specialization information. The evaluation phase is the last phase. Here, the results of the service execution are evaluated and the consecutive services are determined using the temporal connection in the connection information.
6. Related research In [AALS00] Message Sequence Charts and Petri Nets are suggested for the specification and verification of inter-organizational business processes. The focus of this approach is to verify the consistence between inter-organizational business processes and message sequence charts. In [MPSK98] a dynamic business process model is developed. Furthermore concepts for the management of web services are proposed and detailed in [MSLH02]. However, no special enactment architecture is proposed. The eFlow platform [CaIJ00] provides the composition of services and their adaptation to changes such as the introduction of new services. The dynamic composition of services is addressed in the DySCO approach [PiFW03]. The modeling, composition and execution of services are the aim of the FRESCO project [PiZW03]. Both eFlow, DySCO and FRESCO, however, do not provide an enactment architecture. In [NaLS03] the use of rules and events for business process enactment is proposed. There are also coordination related extensions to web services such as the Business Process Execution Language for Web Services (BPEL4WS) [BPEL]. BPEL4WS allows to specify business processes and to define the web services to be used for executing the specified business process [LeRo02].
7. Summary The enactment of inter-organizational business processes is crucial for enterprises which have to quickly adapt or create partnerships with other enterprises to support open process networks and virtual enterprises. The fluctuation of business partners creates new and extended flexibility requirements to the enactment of business processes. The key to fulfil all of these requirements is to use an aspect-element oriented schema representation as part of an indirect enactment architecture. It is implemented by a composite application using specialized web services. The next
8
Rainer Schmidt
steps will be the design of a service weaver and the introduction of tracking and tracing mechanisms.
8. References [AALS00] W. M. P. van der Aalst: Process-oriented Architectures for Electronic Commerce and Interorganizational Workflow. Information Systems, 24(8), 2000 [AWBB93] M. Aksit, K. Wakita, J. Bosch, L. Bergmans, A. Yonezawa: Abstracting Object Interactions Using Composition Filters. In R. Guerraoui, O. Nierstrasz, M. Riveill (Eds.): Object-Based Distributed Programming, ECOOP '93 Workshop, Kaiserslautern, Germany, July 26-27, 1993. LNCS Vol. 791, Springer Verlag, Berlin, 1994. [BPEL] Business Process Execution Language for Web Services, Version 1.0 ftp://www6.software.ibm.com/software/developer/library/ws-bpel.pdf [CaIJ00] F. Casati, S. Ilnicki, Li-Jie Jin: eFlow: a Platform for Developing and Composite eServices. HP Laboratories Palo Alto. Report HPL-2000-36, March 2000. [JaBu96] S. Jablonski, C. Bußler: Workflow Management - Modeling Concepts, Architecture and Implementation. London 1996 [Kicz96] G. Kiczales: Aspect-oriented programming. ACM Computing Surveys, 28(4), December 1996. [LeRo02] F. Leymann, D. Roller: Business processes in a Web services world: A quick overview of BPEL4WS. ftp://www6.software.ibm.com/software/developer/library/wsbpelwp.pdf [LeRo97] F. Leymann, D. Roller: Workflow-based applications. IBM Systems Journal, Volume 36, Number 1, 1997 [MPSK98] J. A. Miller, D. Palaniswami, A. P. Sheth, K. Kochut, H. Singh: WebWork: METEOR2's Web-Based Workflow Management System. Journal of Intelligent Information Systems (JIIS), 10(2), 1994, S. 185 — 215. [MSLH02] J. Meng, S. Y.W. Su, H. Lam and A. Helal, "Achieving Dynamic Interorganizational Workflow Management by Integrating Business Processes, Events, and Rules," Proceedings of the Thirty-Fifth Hawaii International Conference on System Sciences (HICSS-35), January 2002 (pdf). [NaLS03] K. Nagarajan, H. Lam, S. Su: Integration of Business Event and Rule Management with the Web Services Model,” in the Proceedings of the First International Conference on Web Services(ICWS ’03), June 23-26, 2003, Las Vegas, NV. [PiFW03] G. Piccinelli, A. Finkelstein, S. L. Williams. "Service-oriented Workflows: the DySCo framework" To appear: Proc. Euromicro Conference, Antalya, Turkey (2003). [PiZW03] G. Piccinelli, C. Zirpins and W. Lamersdorf: The FRESCO Framework: An Overview. Proceedings 2003 Symposium on Applications and the Internet Workshops Published by IEEE Computer Society, S. 120-123 [W3C] www.w3c.org [W3WS] http://www.w3.org/2002/ws/ [XML] http://www.w3c.org/xml [YaPH02] J. Yang, M. P. Papazoglou, W. J. v. Heuvel: Tackling the Changes of Service Composition in E-Marketplaces, Proceedings of the 12th International Workshop on Research Issues on Data Engineering: Engineering E-Commerce / E-Business Systems (RIDE-2EC 2002), San Jose, USA, 2002
