Model-Driven Process Development Incorporating Human Tasks in Service-Oriented Grid Environments Julian Reichwalda, Tim Dörnemannb, Thomas Bartha, Manfred Grauera, Bernd Freislebenb a

b

Information Systems Institute, University of Siegen, Hölderlinstr. 3, D-57068 Siegen, Germany {reichwald | barth | grauer}@fb5.uni-siegen.de

Department of Mathematics and Computer Science. University of Marburg, Hans-Meerwein-Str. 3, D-35032 Marburg, Germany {doernemt | freisleb}@informatik.uni-marburg.de Abstract: Grid computing infrastructures and service-oriented architectures commonly rely on web services as their implementation technology. This technology allows complex workflows to be designed and executed by workflow engines in either Grid or standard web service environments. Nevertheless, the integration of human intervention in Grid workflows is still a manual, therefore time-consuming and error-prone task, caused by the lack of software support for designing workflows that incorporate human tasks in Grid environments. In this paper, we present a model-driven approach for designing Grid workflows containing human tasks. The solution also covers the automatic creation of user interfaces for human interventions. The approach is implemented and validated by a virtual prototyping process from metal casting.

1 Introduction Workflows are widely understood as completely or partly automated business processes, during which documents, information or tasks are passed from one participant to another one for action, according to a set of procedural rules [All00]. In engineering domains like e.g. sheet metal forming or metal casting in the automotive supplier industry, business processes in product development often incorporate virtual prototyping techniques (e.g. numerical simulation and optimization). The quality of such virtual prototypes highly depends on the knowledge of various experts (e.g. domain experts and computational engineers), making decisions throughout the process (e.g. adjusting optimization parameters or calibrating the prototyping model). Hence, coping with human tasks is mandatory when designing workflows in such domains. Such workflows typically span multiple institutions. On the one hand, several engineers from different domains (i.e. computational engineers, domain experts etc.) have to work in close collaboration and share their knowledge during the process. On the other hand, highly specialized resources like High Performance Computing (HPC) hardware and software for numerical simulations are required, which are typically unaffordable for the gross of the industrial landscape [GRCB06] and therefore do not reside in a single enterprise. The

79

Grid computing paradigm [FK99, FK04] can help to overcome certain barriers which are encountered when trying to interconnect multiple institutions and coevally share computing and storage resources. Since the Grid computing paradigm adopted many concepts from Service-Oriented Architectures (SOAs) [Mas07, SH05] the Business Process Execution Language (BPEL) became subject of interest for representing and executing workflows in web and Grid service based infrastructures [FSF+06]. However, the task of designing or changing workflows that incorporate human tasks in a Grid environment is lengthy and error-prone, since workflow editors either can cope with standard web services and map human tasks to a vendor-specific implementation, or can deal with Grid services, lacking human task implementations. Furthermore, a human task may require some sort of user interface (UI), depending on the task to accomplish. The UI can be realized using any technology, e.g. a web portal or a smart client. The UI needs to interface with the task (and the process, respectively). Thus, creating an adequate UI can be a time-consuming task. In this paper, a model-driven approach for designing and executing workflows in service-oriented Grid environments that may be modeled as interactive workflows is presented, i.e. human intervention is required in certain steps of the workflow. According to the Model-Driven Architecture (MDA) approach [MM03], a platform independent model represents the workflow model and can be combined with additional information about the underlying infrastructure (i.e. technology information as well as the interface used to present human tasks to the user). Both the platform independent model as well as the technology information is transformed to a platform specific model, i.e. to valid code that can be deployed to a workflow engine along with necessary user interfaces. A prototypical implementation using the Globus Toolkit 4 as the Grid middleware and a GridSphere portal as the UI will be presented together with a virtual prototyping application based on a process from metal casting. The paper is organized as follows. Section 2 gives a detailed description of the problems faced by implementing workflows with human tasks in a Grid computing environment. A conceptual solution to these problems is presented in section 3, and a prototypical implementation is described in section 4. In section 5, the implemented prototype is then used to realize an example workflow from virtual prototyping in metal casting. Related work is discussed in section 6. Section 7 concludes the paper and outlines areas for future research.

2 Problem Statement Service-oriented Grid computing already proved to be an adequate infrastructure for supporting virtual prototyping business processes in engineering [GRB07]. In [GRCB06], different roles in a Grid environment have been identified and a value chain for service-oriented computing has been presented especially for scenarios incorporating small and medium enterprises. Grid computing therefore generates value from an economic viewpoint. From the technical perspective, service-oriented Grid computing is a layered architecture, reaching from the physical hardware to the end user. Figure 1 depicts both the economic and the technical view to service-oriented Grid technology.

80

Figure 1: Service-oriented value chain and corresponding technical layers of a service-oriented Grid computing environment

Service-oriented Grid technology is divided into the basic hardware infrastructure (incorporating networks and computing resources) and the service-oriented Grid technology, i.e. standards like Web Services, the Web Services Resource Framework (WSRF) etc. The information processing point of view sees a technology stack, where hardware is interconnected by a middleware, on which services are built. These services may then be orchestrated to higher-level services, representing whole workflows to be used by the end user. From the economic perspective, value is created by first providing the hardware resources and interconnecting them by utilizing a middleware. Service providers are then in charge of providing high level and coarse-grained services, which are orchestrated by integrators to support a specific business process and solve an end user’s problem. The utilization of workflows and workflow engines – in service-oriented architectures typically compliant to the BPEL-standard mentioned before – already allow a fast adoption of complex workflows and can be a great benefit to the integrators, who are in charge of developing adequate workflows to fit the end user’s needs. However, there are several problems that render the workflow design process for integrators as a complicated task. First, still a vast knowledge of technical details is needed. Designing a workflow means knowing the infrastructure the workflow will be executed on, incorporating the middleware and the workflow engine, coping with security issues and knowing BPEL. Second, the support for human tasks in BPEL-based workflows has been integrated into commercial products using standard web service infrastructures (and recently trying to implement the newly released specifications BPEL for People (BPEL4PEOPLE) [AAD+07b] and Web Services Human Task (WS-HT) [AAD+07a]), but the integration into service-oriented Grid computing environments is still missing. Neither applications like BPEL editors exist which are able to cope with Grid infrastructures, nor are they able to provide appropriate interfaces for humans to interact with the process – the user interface for the human task always has to be adopted by hand.

81

As a result, system integrators and workflow designers face a lot of work when creating or adjusting workflows which have to be run on Grid infrastructures and incorporate human tasks. The process has to be defined and modeled, human tasks have to be identified, the workflow needs to be implemented according to the underlying infrastructure and the user interfaces for the interactive tasks have to be defined and created. This time-consuming and costly task has to be shortened and simplified.

3 Solution Architecture As described in section 2, creating or adjusting virtual prototyping workflows in serviceoriented Grid computing environments is a hard task for the integrators with lots of manual and error-prone work to do. Tools for graphical workflow design as well as workflow execution already exist, but either they do not support Grid computing environments or lack features concerning human tasks. A model-driven approach covering both – the service-oriented Grid environment as well as human tasks – will be presented in this section. Workflows with human intervention are different from fully automated workflows in many ways. First, the execution environment must provide some kind of user interface allowing a user to perform the required task. A typical task could be that the user has to enter some values required by subsequent workflow steps. Due to the broad variety of possible workflows and corresponding human tasks it is impossible to provide a generic user interface for arbitrary human tasks. For this reason, our solution allows to deploy custom user interface code for every workflow (see figure 2). This goal is achieved by utilizing the process’s external WSDL representation to determine required input data for human tasks. The WSDL document contains information on data types and names of input variables which can be used to create a custom user interface. This procedure is schematically illustrated in the right side of figure 2. The left side illustrates that platform-specific workflow code is generated using the workflow editor’s internal model. In most cases, the user will not directly enter the required information since for instance workflows often run outside business hours. The workflow execution environment must be able to cope with this highly asynchronous behavior. Ideally, a workflow executing a human task should be suspended until the user’s reply arrives to save hardware resources on the hosting environment. Furthermore, the execution environment should be capable of running many workflow instances in parallel. Then, a solution is needed to correlate the results of human tasks with workflow instances. The asynchronism necessitates a component that stores all outstanding human tasks in a per-user manner. Whenever a new human task is created by a workflow step, it is automatically added to the component’s repository. A task description includes the name of the user the task is attached to, an identifier of the corresponding workflow instance as well as information needed to render the task-specific user interface. Beyond that, the component is equipped with a user interface to display a list of outstanding tasks.

82

Figure 2: Components of our solution and their interaction.

As already stated, workflow developers should be relieved from the error-prone and time-consuming process of manually writing workflows by hand, especially since many workflow languages have not been designed for manual editing. For this reason, a demand for a graphical workflow modeling tool exists. Besides modeling of fully automated workflows, it should provide support for developing workflows containing human tasks. Our proposed solution satisfies this requirement and is even able to automatically generate user interfaces for human tasks as described above. The modeling tool – following the MDA approach – operates on an internal data model and transforms it into an executable workflow description as well as user interface code for the desired target platform. Using this model-driven approach, our solution basically remains independent of concrete technologies. Pluggable target system mapping components transform the internal model into workflow environment-specific code. User interface code is generated by pluggable generators as well.

4 Prototype Implementation A prototype has been implemented according to the solution concept described in the previous section. The Globus Toolkit Version 4 (GT4) has been chosen as the middleware platform, since GT4 can be seen as the de-facto standard for serviceoriented Grid infrastructures. Furthermore, GT4 implements the Web Services Resource Framework (WSRF), which allows the implementation of stateful web services.

83

A Task List Service (TLS) will store and manage human tasks and act as an interface between the user interface and the process. GridSphere, a Java-based portal framework, provides the presentation layer for user interfaces. Since GT4 relies on web service techniques, the Business Process Execution Language (BPEL) is used for workflow modeling, with ActiveBPEL as the execution engine. The prototype system and its action sequence are depicted in figure 3.

Figure 3: Interaction between middleware components when invoking human tasks

The figure shows a BPEL process, reaching an invoke-operation for a human task. In this context, invoking (1) means calling the TLS and storing all necessary task information. At this point, the BPEL process suspends itself until the human task finishes. A user can now log on to the portal (2), and the task list portlet displays a list of open tasks. For each task, the portal provides a user interface. The information entered by the user is reported to the TLS by the portlet (3), which in turn calls the suspended BPEL process (4). The process then collects the entered information and resumes. The TLS has been implemented as a GT4 service following the factory pattern, and stores each task as a resource property. Thus, the WSRF framework implemented by GT4 is utilized. Calling the createResource-operation provided by the factory service creates tasks. During the creation of a new task, a given username is automatically stored in the task object; hence it is possible to grant access to a specific task just to a predefined user. After the resource is created, the correct endpoint reference (EPR) to that resource is returned to the caller. By using this EPR for further calls to the instance service, the caller can uniquely identify the task to modify, process or delete it –

84

necessary operations are provided by the instance service. Additionally, a short description of the task, its actual state, a unique ID, the process URL, the task’s own endpoint reference as well as viewing information for the graphical user interface are saved. In this case, the viewing information is the name of a JSP, but it could also be any other information for rendering the task in a user interface. The task’s own EPR is used by the user interface for calling update or delete methods on the correct endpoint. The process URL is needed by the TLS for calling back the process and transferring data when the task is accomplished. Calling back the process is triggered by the processTask operation, which takes an array of task parameters as argument, consisting of the parameter name as a generic string, the parameter’s data type as a string-represented QNAME and finally the parameter’s value, entered by the human and mapped to the data type Object. A generic SOAP client then takes the parameters and transfers them to the waiting process, using the process URL stored in the task object. Due to the fact that it is possible to have multiple workflows waiting to be resumed, the correct workflow instance is identified by BPEL correlations, technically achieved by adding correlation-related code to the process’ WSDL file (see listing 1).

Listing 1: Correlation related additions to the process’ WSDL file The utilization of GridSphere as the portal system requires JSR-168 compliant portlets, which can be arbitrarily arranged by users inside a standard web browser. In our prototype, a portlet also takes care of displaying the human tasks to the user and also providing the possibilities to accomplish them (as far as user input is required). Each portlet consists of an implementation class that realizes the processing logic, while a JSP is responsible for rendering the user interface. In this context, the portlet implementation class calls the TLS for all open tasks for the user who is currently logged in. The information will be passed to a JSP, which is in charge of displaying the open tasks as a list, incorporating a unique task identifier, the description and a link to process the task. Since processing different tasks will result in different user interfaces, the task itself will provide the portal with the appropriate JSP that has to be shown for processing and entering data. When the user finishes the task, the data is passed to the implementation class, which in turn calls the TLS for updating the process with the corresponding data entered by the end user. Modeling of BPEL workflows is a complex challenge, and tool support is needed to ease this error-prone and time-consuming task. Especially when correlations are involved to model asynchronous invocation behavior (as needed when human intervention is required) the process description becomes cluttered. To release the workflow designer from manually writing code, extensions to an Eclipse based workflow designer [FSF+06] have been developed (figure 4 shows a screenshot of the editor).

85

Figure 4: Screenshot of the Eclipse-based workflow editor

Modeling human tasks is made as easy as dragging the human task symbol from the editor’s palette to the desired location in the workflow. Then, a graphical wizard pops up and asks for required information. The user has to provide the location of the TLS, which can be selected from a dropdown box of pre-configured services or added manually. All other information like the aforementioned JSP URL, username etc. are automatically created and used in the gridInvoke operation (see listing 2). In the next step, the workflow designer has to decide which input should be requested by the corresponding JSP interface. The editor creates appropriate messages and variables for the BPEL process and adds them to the receive operation, which resumes the process when the required data is submitted by the user using the portlet.

Listing 2: Correlation related additions to the process logic

86

After finishing the design of a process, it has to be exported from the BPEL editor. In doing so, the process’s internal representation is transformed into valid BPEL code. For every human task in the process, a code generator is run. It retrieves required information, namely data types, message names and JSP name, from the process’s internal model and generates JSP pages with the given names for every human task. Thus, the BPEL editor can be seen as a one-stop-shop application for the creation of workflows involving human tasks since it also automatically creates user interfaces and callback code for the GridSphere portal solution.

5 Sample Application As a sample application, a workflow from virtual prototyping in metal casting industry has been taken. The process in figure 5, displayed as an event-driven process chain (EPC), depicts a section of a virtual prototyping process (detailed information about the whole process can be found in [GRB07]). During the process, the Model Calibrated event triggers a human task Prepare Optimization, where an optimization expert needs to prepare an optimization run (i.e. entering parameters for the algorithm which cannot be determined automatically etc.). When the task is finished, the process will be continued and the optimization can be started. The model has been transferred to the workflow editor and the Prepare Optimization function has been annotated as a human task. A GT4 based infrastructure offers the Start Optimization Grid service (in this case: a numerical optimization of a metal casting process), while Prepare Optimization – as a human task – does not have any specific Grid service representation. Start Optimization expects some parameters to configure an optimization algorithm. When the process is going to be exported, the workflow model is combined with information about the underlying infrastructure (i.e. GT4 and the ActiveBPEL enactment engine) and with the representation technique for human tasks (in this case: the GT4 TLS and the GridSphere portal). The result (shown in fig. 5) is the PSM, consisting of executable BPEL code as well as the auto-generated JSP for displaying the human task. A link between the JSP and the BPEL process is made through the TLS which directly interacts with the workflow on the one hand, and with the GridSphere portlet (the JSP and the implemented portlet class) on the other hand. In our experiments, the process could be successfully deployed to the ActiveBPEL engine and the JSP was deployed automatically to the GridSphere portal. When the process was executed, a task was created in the TLS by the workflow, and the process stopped and waited for input provided by the specified user. This user could now log in to the portal where the Task List Portlet automatically received the list of open tasks from the TLS. Processing the task linked the user to the generated JSP, where the appropriate input could be provided and returned to the task list portlet, which immediately informed the TLS about the input provided. The TLS then called back the waiting process instance (which could be uniquely identified by using the correlation sets), and the process continued and was able to call Start Optimization with the userprovided input.

87

Figure 5: The left side shows the example process as an event-driven process chain, the right side depicts a schematic view of the transformation for the sample process.

6 Related Work In this section, related research in the area of Grid service based workflows is discussed. Since the area of Grid workflow modeling is quite well researched (see [YB05] for an overview) and many different approaches and tools exist, we only present some representative approaches. The P-GRADE Portal [KS05] is a workflow-oriented Grid portal which integrates both workflow modeling and execution in a collaborative environment. It provides functionality for defining Grid environments, creation and modification of workflows, certificate management as well as controlling and monitoring workflows. However, it does not feature the development of workflows with human interactions nor the creation of user interfaces for human intervention. Triana [TSWH05] is a Grid workflow system that abstracts from underlying technologies by making use of the GAT API. This allows to seamlessly using services which incorporate different technologies, like Condor, Unicore, and WSRF or even lowlevel services such as SGE or SSH. Like our approach, Triana offers a graphical modeling tool. Quite similar to Triana is the approach taken by Taverna (http://taverna.sourceforge.net/) with the difference that Taverna does not include a graphical editor. Both do not implicitly feature human tasks in workflows.

88

The GridFlow [CJSN03] workflow management system applies a more complex workflow model. It handles workflows at two levels: a global Grid level and the level of local Grid (typically one or more clusters in the same organization). Workflows for GridFlow are modeled using a graphical editor named GridFlow portal. It provides scheduling capabilities for local Grids and is not designed to support tasks with human interventions. Wassermann et al. [BWP07] describe their implementation of a BPEL-based environment for visual scientific workflow modeling. It consists of a workflow engine based on ActiveBPEL and a visual editor. To ease the modeling of scientific workflows the authors introduce several visual abstractions from the BPEL syntax. The visual abstractions are mapped to standard BPEL code so that no modifications to BPEL are necessary. The feasibility of their approach is demonstrated by a real-world example with completely automated workflows from computational chemistry. Nevertheless, the authors do not address human tasks at all.

7 Conclusions and Future Work In this paper, we have described the problems of workflow designers and integrators when faced with business processes incorporating human tasks. The lack of adequate tool support and the complexity when manually trying to create the workflows and the user interfaces was discussed. A new approach to solve the problem by utilizing the MDA approach was presented, resulting in visually designing a platform-independent workflow representation and automatically combining it with the underlying platform information and user interface representation techniques. Our approach was validated by applying it to a virtual prototyping process from the metal casting industry. In the future, the user should get the possibility to change the information presented in the human task user interface, i.e. the layout etc. Changes could be done by also providing a graphical modification system and extending the editor with the functionality. Furthermore, supporting the WS-HumanTask and BPEL4PEOPLE specifications to gain more standard compliance is desired. This step would also allow workflow designers to combine standard web services and Grid services in a single workflow, and human tasks could be arbitrarily mapped as either a Grid solution or a vendor-specific implementation.

Acknowledgments The work presented in this paper is partly supported by a grant from the German Ministry of Education and Research (BMBF) (D-Grid initiative, InGrid Project) and by the Ministry of Science and Research of Northrine-Westfalia out of the MiGrid-Project. Furthermore, we would like to thank our industry partner ACCESS e.V. for providing the software and the use cases necessary for this work.

89

References [AAD+07a] A. Agrawal, M. Amend, M. Das, et al. Web Services Human Task 1.0, June 2007. [AAD+07b] A. Agrawal, M. Amend, M. Das, et al. WS-BPEL Extension for People (BPEL4People), Version 1.0, June 2007. [ACD+03] Tony Andrews, Francisco Curbera, Hitesh Dholakia, Yaron Goland, Johannes Klein, Frank Leymann, Kevin Liu, Dieter Roller, Doug Smith, Satish Thatte, Ivana Trickovic, and Sanjiva Weerawarana. Business Process Execution Language for Web Services Version 1.1. Microsoft, IBM, Siebel, BEA und SAP, 1.1 edition, May 2003. [All00] R. Allen. Workflow: An Introduction. In L. Fischer, editor, The Workflow Handbook 2001, Chapter 1, pages 15–38. Future Strategies, 2000. [AMA06] A. Akram, D. Meredith, and R. Allan. Evaluation of BPEL to scientific workflows. In Proceedings of Cluster Computing, 2006. [CJSN03] Junwei Cao, Stephen A. Jarvis, Subhash Saini, and Graham R. Nudd. GridFlow: Workflow Management for Grid Computing. In CCGRID, pages 198–205. IEEE, 2003. [DFH+07] Tim Dörnemann, Thomas Friese, Sergej Herdt, Ernst Juhnke, and Bernd Freisleben. Grid Workflow Modelling Using Grid-Specific BPEL Extensions. In Proceedings of German eScience Conference 2007, http://edoc.mpg.de/316604, 2007. [EBC+05] W. Emmerich, B. Butchart, L. Chen, B. Wassermann, and S.L. Price. Grid Service Orchestration using the Business Process Execution Language. Journal of Grid Computing, 3(34):283–304, September 2005. [FK99] Ian Foster and Carl Kesselman, editors. The Grid: Blueprint for a New Computing Infrastructure. Morgan Kaufmann Publishers, San Francisco, 1999. [FK04] I. Foster and C. Kesselmann, editors. The Grid 2: Blueprint for a new Computing Infrastructure. Morgan Kaufmann, 2004. [FSF+06] T. Friese, M. Smith, B. Freisleben, J. Reichwald, T. Barth, and M. Grauer. Collaborative Grid Process Creation Support in an Engineering Domain. In Y. Robert et al., editors, Lecture Notes in Computer Science (LNCS), volume 4297, pages 263–276, Berlin, 2006. Springer. [BWP07] B. Butchart N. Cameron L. Chen B. Wassermann, W. Emmerich and J. Patel. Sedna: A BPEL-based Environment for Visual Scientific Workflow Modelling, pp.428–449. Springer, 2007. [GRB07] M. Grauer, J. Reichwald, and T. Barth. A Service-Oriented Grid-Based Infrastructure for Supporting Virtual Prototyping in Manufacturing. In A. Oberweis, C. Weinhardt, H. Gimpel, A. Koschmider, V. Pankratius, and B. Schnizler, editors, eOrganisation: Service-, Prozess,- MarketEngineering, volume 2, pages 531–548, 2007. [GRCB06] M. Grauer, J. Reichwald, D. Christian, and T. Barth. The Potential of Service-Oriented Computing for Small and Medium Enterprises - Analysis of Value Chains. In P2P and Grid Track, Multikonferenz Wirtschaftsinformatik, Passau, 2006. [Gri07] GridSphere Portal Framework. http://www.Gridsphere.org, Last Visited: September 2007. [IBM01] IBM. Web Services Flow Language, 2001. [KS05] Péter Kacsuk and Gergely Sipos. Multi-Grid, Multi-UserWorkflows in the P-GRADE Grid Portal. J. Grid Comput, 3(3-4):221–238, 2005. [Mas07] D. Masak. SOA? Serviceorientierung in Business und Software. Springer, 2007. [Mic01] Microsoft. XLANG - Web Services for Business Process Design, 2001. [MM03] J. Miller and J. Mukerji, eds. MDA Guide Version 1.0.1. OMG, 2003. [SH05] M.P. Singh and M.N. Huhns. Service-Oriented Computing - Semantics, Processes, Agents. John Wiley and Sons, 2005. [TSWH05] Ian J. Taylor, Matthew S. Shields, IanWang, and Andrew Harrison. Visual GridWorkflow in Triana. Journal of Grid Computing, 3(3-4):153–169, 2005. [W3C] World Wide Web Consortium W3C. Web Services Definition Language (WSDL) 1.1. http://www.w3.org/TR/wsdl. [YB05] Jia Yu and Rajkumar Buyya. A Taxonomy of Workflow Management Systems for Grid Computing. Journal of Grid Computing, 3(3-4):171–200, 2005.

90