Extensible Process Support Environments for Web Services Orchestration

Transcription

1 International IEEE Conference on Next Generation Web Services Practices August 22-26, 2005, Seoul, Korea Extensible Process Support Environments for Web Services Orchestration Jacky Estublier, and Sonia Sanlaville LSR-IMAG, 220 rue de la Chimie BP53, 3804 Grenoble Cedex 9, France {Jacky.Estublier, Abstract Processes can be used to integrate, coordinate and interact with many actors and software in many application domains; their range of needs and objectives is virtually unlimited. A system fitting all needs would be huge and complex, too hard to use and evolve, but on the other extreme, developing many specialized Process environments for each need would lead to a situation where many independent and incompatible process islands prohibit a consistent and global process management of a company. This paper proposes an approach where a process environment can be tailored to specific needs, most notably for Web service orchestration. We illustrate the approach by an example and justify it by the validations we have made.. Introduction A process is the way a company uses its resources to perform its work. A process model is a formal (or at least explicit) way to represent a process. A process environment is a computerized system, supporting some of the activities related to processes, including their capture, elicitation, definition, execution, improvement and so on. Processes can be used to coordinate very different systems : industrial production (e.g. car builders), services (e.g. tourism), software developers (e.g. software vendors), business (e.g. banks) and of course web services. For this reason it is difficult to talk about process support environment in the abstract, it is an open world, with unclear and moving boundaries. Following most work performed in the Process Support Environments (PSE) area, a process model is governed by a metamodel (be it formal or not). A metamodel covering all potential uses of processes is impossible to define and even if it existed, it would be so big and complex that it would be unusable. Fortunately, each process use has specific characteristics and limited needs, making reasonable to define a specific metamodel and the corresponding PSE for each one of them. Clearly, the problem is that it is not economically feasible to build a different PSE for each company and even if it was, since the company evolves, the PSE should be reworked permanently. A specific metamodel for every given specific use or company, or even a limited range of the same, is not only economically unrealistic, but at the same time it does not provide a satisfactory solution. Nevertheless, in order to address the largest possible market, PSE vendors seek to develop PSEs capable to address a market segment as wide as possible but, not only is this market segment not as wide as expected and the modeling capabilities not very deep, but also the resulting PSE is a large and monolithic piece of software. Even with a wide scope PSE, it is likely that the user has a specific need on a tiny part of the system (e.g. orchestration) and, as it is monolithic, its extension is often too expensive to be performed, and efficiency too poor. Altogether, the situation is not satisfactory, to say the least. Along the last 0 years our research work has been to try to find a satisfactory solution to these issues; simply stated: how to build simple, easily extensible PSEs, that can orchestrate different and heterogeneous components (Web Services, Object Oriented, component technology, COTS, etc.). In this paper, we propose an approach to build process support environment extensible and evolutive. Section 2 introduces our platform Melusine. We present in section 3 our proposition, which identifies four classes of extensions. Section 4 presents an evaluation of our approach. A discussion of related works and concluding remarks completes this paper. 2. The Melusine platform architecture Our platform, Mélusine, allows designing, implementing and executing processes that are able, among other things, to coordinate humans, tools and Web services. Software applications designed with Mélusine have a three-layer architecture: the conceptual layer (supporting the process and the coordination) the mediation layer (adaptation between the conceptual layer and the current services) and

2 the tools and web services. We discuss in this section the rationale that led us to define such an architecture. 2.. The conceptual layer Mélusine supports the concept of conceptual domain, which is the metamodel of an application area. Mélusine philosophy requires that the conceptual domain only contain the core concepts, relevant in the considered application domain. Following the Mélusine philosophy, Process conceptual domain [8], [9], [0], [4] only contains the core process concepts: activities, ports, products, roles, data flow (Figure ). +subactivities Role +playrole..n Resource Activity +entryport +exitport +desktop Port DataFlow Product Product Type Figure. The Mélusine process Metamodel Mélusine process domain supports dynamic evolution; at any point in time it is possible to change the process model, or anyone of its instances, by adding/removing activities, data flows, products or resources. Changes performed on an instance have effect on this instance only, while changes on a model have effect on any future execution of this model. The ADEPT workflow system [2] is among the few proposing similar dynamic capabilities. The Mélusine process domain graphical language is simple and at a high level of abstraction (see Figure 2) where activities are rectangles linked by data flow. Figure 2. A process model example At execution, this model is instantiated each time a document needs to be edited. This execution is performed in the conceptual layer and communicates with the mediator layer just below The Mediator layer Traditionally, the process model directly indicates which are the tools (or web services) involved in an activity [2]. This coupling the process model to the tools is inconvenient since the process model represents the what and the tools the how. Therefore, we believe that the process pertains to the conceptual layer and must be kept independent from the tools, web services and devices that will be used to implement the activities. Relating both layers is the duty of the mediation layer. The mediation layer contains adaptors (Figure 3); an adaptor is a sequence of calls to the tools that implement the activity. Mélusine supports different classes of tools; a tool can be local, distant, client server or a web service; it can be ad hoc or COTS in a transparent way. Mélusine also supports different communication protocols: RMI, socket or SOAP. Tools and communication protocols can be modeled statically and/or defined and changed dynamically. Figure 3 shows how the process model presented in Figure 2 can be linked to the tools. When Edit activity starts, adaptor A is launched, that calls Editor Web Service. When Edit activity is over, Review activity starts, A2 is called and A2 adds this activity in the reviewer Agenda Tool. Conceptual layer process instance "Edit a specification document for P production" workflow Adaptor A Mediation layer Editor service Adaptor A2 Reviewer service Tools layer Editor Web Service Agenda Tool Figure 3. The Mélusine three-layer architecture Mélusine platform supports persistency, failure recovery, run time monitoring, orchestration and dynamic evolution during execution. 3. Evolution We propose in this paper a method and an environment for building extensible process support environments. In our approach, the core process support system only contains the basic process concepts, but this core metamodel can be extended, in order to include new concepts or to change the semantics of the existing core concepts. This section presents how a core metamodel can be extended. We have identified fours classes of extensions that can be applied to an existing metamodel: Behavioral Extension, that changes the behavior of the concepts already existing in the metamodel. Metamodel Extension, that adds new concepts to the current metamodel. Refinement, that provides a more detailed definition of a concept already present in the core metamodel. Composition, that builds a new metamodel by combining two existing and independent metamodels. It is possible to combine these different kinds of extensions, providing a very wide range of possibilities for extending a metamodel. These kinds of extensions are described bellow.

3 3.. Behavioral Extension (features) Behavioral extensions correspond to the modification of the metamodel behavior; with respect to the default behavior. For example, in the process domain, one may want to store execution traces; it means that the behavior associated to starting and ending an activity will also save some information in a file, like the date, the responsible of the activity and so on. Behavioral extensions are implemented by specific adaptors, that capture the set of standard behaviors and redefine or change them. New tools may be needed to implement the extended behavior. In our example, the adaptor captures the start and end of all activities, and calls the Trace tool. Depending on the Trace tools selection, the trace can be saved on different media and in different formats. We call feature this kind of extension, since it is an optional behavior and the user may decide to use it or not. It is enough to select the features and the extended behavior becomes active. It is important to notice that a feature do not change the current metamodel and in particular, no new concept is added. Process meta-model 3.2. Metamodel Extension Metamodel extension consists in adding new concepts and associations to the current metamodel. In our process domain, a possible extension could be exception management. It requires defining the concept of exception (three classes of exceptions are defined in the example below) and the associated behavior (defining exception scope, detection and handling). In other words, we have to define a metamodel for exception handling and to indicate how these concepts are related to the process concepts (Figure 4). In practice, this means that we have to define the associations between the process concepts, as found in the process metamodel and the exception concepts, found in the exception metamodel. In this example, we have defined that an activity may have an associated deadline, a port may have conditions and an activity may receive an exception. We have to define the semantics of these associations, for example that if an activity is not finished at deadline, it will receive an exception. A detailed description of exception handling is out of the scope of this paper. The relationships between the core domain and the extension have to be analyzed at three levels: metamodel, model and instances. depends_of Exception meta-model meta-model level «M 2» +subactivities Role +playrole..n Resource Activity +entryport +exitport +desktop Port DataFlow Product Product Type depends Alarm Exception Condition Exception Condition Coherence Exception model level «M» Conform_to Process model "Edit Doc" workflow instance_of Process instance "Edit a specification document for P production" workflow Conform_to synchronizersexception model Review Alarm Review Edit Alarm Edit instance_of instance_of Exception instance Review Alarm send message «M0» Figure 4. Metamodel Extension synchronizers Review at 5/02/2005 8:00 PM Metamodel level. The new concepts (Exception,, Condition) are associated with the classes that perform the job (starting an alarm for the deadline and so on) and the associations (Exception / Activity, Activity /,Port / Condition) are implemented as synchronizers. A synchronizer links a core concept with an extended concept, it captures the relevant event occurring in the core concept (in the example, it captures activity start and termination) and

4 it calls the classes in the extension, providing the relevant information (context, parameters and so on). instance with the right information and links it to the activity that has reached its deadline (Figure 6). The exception instance, through its adaptor may launch a tool for the exception management (like calling a web service, starting specific exception management and so on) Refinement Figure 5. Process exceptions model editor Model level., Condition and Exception concepts are now part of the extended metamodel, therefore the actual activities found in the existing (and future) models may be associated with deadlines and exceptions. This shows that the extension propagate to the model level. For reusability reasons, the existing models should not be modified. This can be solved by developing new models expressing how the entities present in an existing model are extended. In our example, a process exception model editor has been developed that takes as input the graphical representation produced by the process model editor, and annotates it with the deadline and exception information. This is illustrated in Figure 5 where Review activity will be associated with a deadline. For each association activity-deadline this editor generates the code that only captures those activities having a deadline and provides the synchronizer with the deadline value associated to the current activity. Conceptual layer process instance exception instance synchronizers Edit spec document for P production workflow Tools Adaptor Editor Web Service Adaptor Agenda Tool Clock Tool Review Alarm send message Review at 5/02/2005 8:00 PM Exception Manager Web Service Figure 6. The deadline and alarm extensions at execution Instance level. At execution, the synchronizer is started for the right activities only; the synchronizer collects the needed information, creates the deadline instances with the right initialization information (the date and time for the actual deadline) and maintains a link between both instances (activity/deadline). When the deadline instance receives the clock signal, it instantiates an exception The basis of the approach is to use a very small metamodel, containing Activity, Product, Port, Role and DataFlow. These concepts are extremely simple, they do not contain any detail; this is particularly true for products that only have a name (a string) and a type (a string). Clearly, in real applications, products are much more than a name. A product can be a record in a database, a file, or thousands of files and directories, it can be a product in a CAD tool and so on. For each application, there is a need to refine some concepts, to fit the application reality. Refinement consists in providing the complete definition for a concept that already exists in the core metamodel, but is not enough precise. For example, in our process metamodel, the product concept is only a placeholder for the real definition of product, as used in the application at hand. Refinement is realized by establishing a (refinement) link between the product concept, as found in the process domain, with the document concept in the document metamodel. The refinement relationship is by nature a - relationship, each product will be considered dynamically as being a document containing files and attributes. This relationship is implemented in the same way as the extension relationship Composition The extension and refinement techniques do not allow to build an application managing a concept not present in the metamodel concern. This limitation is severe, since it implies that, either the applications will be limited to a given functional area (process in our example), or the core metamodel contains all the concepts that may be useful for at least one application. To build large applications, covering concerns not defined a priori, the metamodel should be extended with other autonomous domains that already exist, so independent domains have to be composed. Composing two metamodels means establishing associations between their concepts and maybe also defining new, emerging concepts. In our example, we have defined a workspace domain, managing private copies of files and directories in the current

5 user machine, and associating tools and actions to these files. +subactivities Process meta-model Role +playrole..n Resource Activity Workspace directory +entryport +exitport +desktop +current +historic File User Item Port Directory DataFlow Product Product Type composition Workspace meta-model..n Figure 7. Process and Workspace meta models composition Composing the workspace domain with the process domains means establishing an association between Activity and Workspace, and between Port and Workspace (Figure 7). The first one is used to synchronize activities and workspace: when an activity instance is created/deleted, a workspace instance is created/deleted in the machine of the user responsible of that activity and a link is established/deleted between the two instances. The link between port and workspace synchronizes the products arriving/leaving the port of an activity with the associated files being copied/removed from the associated workspace, in which the tools and actions defined in the workspace model are executed. 4. Experimentations and validation Mélusine system presented above is the result of a long work on process support, that we started in the late 80s. The idea of defining a core process metamodel (presented here) and to provide a refinement mechanism appeared in the Hence we have built our first composite domain (Process = Activity + Product + Resource). When this process domain was used in industrial applications, it became clear that there was a need to reuse the tools used in the company. We added the mediator and adaptor layers, that proved to be very appreciated. The behavioural extensions where required to select the tools, to adapt to some implementation requirement, or to some user specific tuning; composition was then introduced to coordinate tools from other domains []. Curiously, the metamodel extension ideas were the last ones to be introduced. The extension of the process composite domain became necessary in order to support web service coordination [2]. Not only exception handling has been (re) introduced, but also conversation specific extension and transaction management have been designed. Interestingly, the dynamic capabilities of our process system has not been used so far. We had no demand for such a functionality (too early or unneeded) 5. Related works Process technology was a very active field in the 90s, mainly targeting software processes, i.e. processes including human beings and containing creative tasks [6], [3], [3]. Addressing complex issues of non determinism and creative tasks, these works have had little direct practical impact; by contrast, the works of the workflow community, targeting simple, static and deterministic task automation have been gradually adopted by industry [5], [7], [20]. Recently, the process ideas have surfaced again for program coordination and more specifically, for web service orchestration. Various textual formalisms have been proposed: BPEL4WS (Business Process Execution Language for Web Services) [], BPMN (Business Process Modelling Notation) [8], [9], BPML (Business Process Modelling Language) [2], XLANG [6] and WSFL (Web Services Flow Language) [4]. Each one of these formalisms relies on the process technology, but uses a different metamodel. Similar to our approach, works like [7] emphasize the importance of separating concerns in the processes; [2][22] advocate for dynamic workflow and workflow composition. In contrast to our work, they do not propose any general extension and composition mechanisms. Plug-in approach [5] has similarities with our metamodel extensions and behavioural extensions but, in contrast with plug-ins, our extensions do not need to be established beforehand. Composition of independent domains is not possible with plug ins. 6. Conclusion Process technology can be seen as a coordination (orchestration) technology, to be used by any complex application built from existing pieces, in virtually any application domain, web service orchestration being a

6 special case. This context is very demanding since the concepts and the technical requirements are very different. We believe that traditional process technologies cannot propose any reasonable solution to these problems. We do not have the ambition to propose the perfect solution, fitting all needs; on the contrary, we propose to start with simple metamodels and the associated support, reusing the existing tools and offering a large range of possible extensions. Our work has been focused on the technologies, concepts and methods for extending a metamodel; we have identified four classes of extensions: Behavioral extension, that changes the semantics of metamodel concepts: Conceptual extension, that adds new concepts to the core metamodel concepts; Refinement, that gives an enriched definition of the metamodel concepts; Composition, that allows interoperation of independent and autonomous domains. We believe the flexibility, as well as the range of possible extensions that can be addressed in our environment, are currently not matched by any other technology we know. This technology has been primarily used for process support and a number of industrial process based applications have been implement, it has been extended to support Web service orchestration, still reusing the very same Activity core. We believe that our system is probably one of the very first, if not the first, that can support a wide range of processes, including workflow, software process and web service orchestration equally well. References [] Andrews, T., Curbera, F., Dholakia, H., Goland, Y., Klein, J., Leymann, F., Liu, K., Roller, D., Smith, D., Thatte, S., Trickovic, I., Weerawarana, S.: IBM specification: Business Process Execution Language for Web Services. version. (2003). [2] Arkin, A.: Business Process Modeling Language. Intalio (November 3, 2002). [3] Armenise, P., Bandinelli, S., Ghezzi, C., Morzenti, A.: Software Process Representation Languages: Survey and Assessment, In Proceedings of the 4th International Conference on Software Engineering and Knowledge Engineering, IEEE, Capri Italy, (June 992) [4] Belkhatir, N., Estublier, J., Melo, W. L.: Software process modeling in Adele: The ISPW-7 example. In I. Thomas, editor, Proc. of the 7th Int l Software Process Work-shop, San Francisco, CA, IEEE Computer Society Press (October ). [5] Clayberg, E., Rubel, D.: Eclipse: Building Commercial- Quality Plug-Ins. Addison Wesley Professional (2004) [6] Conradi, R., Fernstrom, C., Fuggetta, A., Snowdown, B. Towards a Reference Framework for Process Concepts. In Proc. EW SPT 92, 2nd European Workshop on Software Process Technology, Trondheim, Norway (Sept. 992) [7] Estublier, J., Dami, S., Amiour, M. : High level process modelling for SCM. 7th. International Workshop on Software Configuration Management SCM7, Boston, 9-20 (May 997) [8] Estublier, J., Dami, S., Amiour, M.: APEL: A Graphical yet Executable Formalism for Process Modeling. Automated Software Engineering, ASE journal. Vol. 5, Issue (998). [9] Estublier, J.: Federations of Process Support Systems. Workshop on Process Modeling (WPM), Zurich, Suisse (2 Octobre, 998). [0] Estublier, J., Amiour, M., Dami, S.: Building a federation of Process Support System. WACC Work, Activity Coordination and Cooperation; Siplan, Sigmod, Sigsoft conference; San Francisco USA (22, 26 February 999). [] Estublier, J., Villalobos, J., Le, A.T., Sanlaville, S., Vega, G.: An Approach and Framework for Extensible Process Support System. 9th European Workshop on Software Process Technology EWSPT 2003, Helsinki, Finland (September 2003). [2] Estublier, J., Sanlaville, S.: Business Processes and Workflow Coordination of Web Services. IEEE International Conference on e-technology, e-commerce and e-service (EEE-05), Hong Kong (March 2005). [3] Heimbigner, D.: The ProcessWall: a Process State Server Approach to Process Programming. ACMSDE, (December 992) [4] Leymann, F.: Web Services Flow Language (WSFL.0). IBM Software Group (May 200). [5] Leymann, F., Roller, D.: Workflow-based applications. IBM System Journal. Vol. 36, No. (997) [6] Satish, T.: XLANG: Web Services for Business Process Design. Microsoft (200). [7] Schmidt, R., Assmann, U.: Extending Aspect-Oriented Programming in Order to Flexibly Support Workflows. In Proceedings of the ICSE98 AOP Workshop, Kyoto (April 998) pages [8] White, S. A.: Introduction to BPMN. BPTrends, < (July 2004). [9] White, S. A.: Using BPMN to Model a BPEL Process. BPTrends, < (March 2005). [20] Workflow Management Coalition: Interface : Process Definition Interface. WfMC TC-06 (August 996) [2] Reichert M., Rinderle S., Dadam P. ADEPT Workflow Management System: Flexible Support For Enterprisewide Business Processes. Proc. Int'l Conf. on Business Process Management (BPM '03), Eindhoven, The Netherlands, June 2003, LNCS 2678, pp [22] Heinlein C.: Workflow and process synchronization with interaction expressions and graphs. In: Proc. Int l Conf. Data Eng., Heidelberg (200)