Proceedings of I-KNOW ’06 Graz, Austria, September 6 - 8, 2006

Service-Oriented Task Management Uwe V. Riss, Olaf Grebner (SAP Research, Karlsruhe, Germany {uwe.riss|olaf.grebner}@sap.com)

Abstract: Pattern-based Task Management (PBTM) has been recently suggested as a paradigm to support knowledge-intensive work due to its flexibility regarding process changes. In the present paper we discuss how a PBTM can be implemented using Web Services (WS). The approach reverts to structural similarities between PBTM and WS. It will be discussed how the PBTM can be realized in a service-oriented architecture. Such an approach can be seen as basis for task handling in an inter-organizational frame, supporting outsourcing and virtualization. Keywords: Web Services, Task Management, Process-oriented Knowledge Management Categories: H.1, H.4

1

Introduction

This paper1 examines the possibilities of implementing the conceptual framework of pattern-based Task Management (PBTM) in the technological framework of Web Services (WS). A PBTM is characterized by the fact that it offers process support for human task handling instead of prescribing the proceedings to the users [Riss et al. 05]. Its goal is to offer a high degree of flexibility in performing tasks and simultaneously to enable reuse of process expertise in a network of users based on the users’ task executions. Such flexibility is especially required for knowledge-intensive work (KIW) which is insufficiently supported by means of information technology so far. A possible technological basis for a PBTM is that of WS [Erl 05]. WS enable the creation of composed and distributed applications and thus meet the requirements of PBTM regarding flexibility and adaptability. Despite the structural similarity between PBTM and WS, there are also differences. WS are mainly designed to support automated processes, based on completely programmed applications, whereas PBTM aims at human-based work. Nevertheless the use of WS is attractive. First, we can regard the different focus on automated and personal proceeding, respectively, also as motivation due to the growing relevance of integrating automated and human-based services in the future. Second, from an inter-organizational point of view, certain standardizations of interfaces and independence of a specific technical platform for PBTM are mandatory. An inter-organizational task management will be a central leverage to establish virtual enterprises [Soares et al. 00]. In this respect the extensive standardization related to WS, e.g., XML, SOAP, HTTP, WSDL, is helpful to establish an inter-organizational Task Management. Looking at recent projects like [1] The work published in this paper is (partly) funded by the EU through the NEPOMUK IP; http://nepomuk.semanticdesktop.org.

Riss U.V., Grebner O.: Service-Oriented Task Management

355

DIP2 we finally find that the WS idea has been extended towards the concept of the Semantic Web. Such efforts can be utilized for PBTM in terms of semantics and coordination of services. The use of WS to realize work processes is not new, e.g., the DynaFlow project realizes an interoperable workflow management by WS [Meng et al. 05]. There are also various standardization efforts, e.g., Wf-XML and ASAP [Swenson 05]. In the following, however, we will focus on the characteristics of PBTM. In [Section 2] we outline the theoretical frame and architectural aspect of a PBTM. In [Section 3] we discuss the integration of PBTM in a WS framework.

2

Pattern-Based Task Management

The principles of the current PBTM have been described in [Riss et al. 05] and shall only be recapitulated to single out the aspects that are important for the WS framework. Central component of a PBTM is the Personal Task Management (PTM) as an individual user tool. It can contain various task instances which describe different units of work that the user has to accomplish. As support for the execution of tasks users can retrieve task patterns provided by a Task Pattern Service (TPS). In particular these task patterns suggest a decomposition of the task into a sequence of sub-tasks (process patterns). These sub-tasks serve as triggers (initiated by a task requester) for new tasks (assigned to a task executor). In this sense tasks are recursive; processes are realized by the interplay of tasks and not by explicit process models. Users are free to change the suggested schema according to their individual needs. Each of these deviations changes the process, in which this task is involved, and users are asked to update the applied pattern in this case. Beside process patterns the TPS also provides context dependent information units (IU) to support the task execution. Both process patterns and IU originate from the common pool of case information. The structure is based on the analysis from several perspectives in analogy to workflow analysis of [Jablonski and Bussler 96]. In particular we have placed emphasis on the following perspectives: (1) the Function Perspective describing the set of sub-tasks that are involved in a task as well as the context independent task data and information, e.g., the general task goal; (2) the Control Perspective describing the logical dependencies between sub-tasks as well as possible business rules (given by organizational standards) that influence the control flow; (3) the Information Perspective describing the context dependent data and information, e.g., input data, that augments the task pattern resulting in a concrete task; (4) the Organization Perspective specifying the possible assignment of tasks to users, e.g., on the basis of role and expertise; (5) the Resource Perspective describing which kind of resources are handled by the task, e.g., required input or output deliverables. Input and output are divided into IU and Resource Units (RU) describing external resources for the task. Some aspects of the structure are visible to the task requester. However, all information and resources that are exclusively used internally are

[2] Data, Information, and Process Integration with Semantic Web Services: an Integrated Project supported by the IST programme of the EU; http://dip.semanticweb.org.

Riss U.V., Grebner O.: Service-Oriented Task Management

356

generally hidden from the requester. The functional perspective is mainly hidden from the requester unless the task pattern is used again and reverts to already existing context information (this is explained more explicitly in the following section). Information and resources perspectives are known inasmuch they are provided as input by the task requester. The organizational perspective is transparent in the sense that requesters might suggest a possible executor putting forth their personal experience.

3

Service Oriented Task Management

We particularly turn our attention to the compatibility of PBTM and WS. In the first instance it is not relevant whether the applied services are based on Web-based standards like XML, SOAP and UDDI or are realized by middleware approaches such as CORBA or DCOM; we will simply refer to them as services. The relevance of their particular WS character will be discussed in the following section and is explained in detail in [Grebner 06]. We will distinguish several services: (1) a Task Service (TS) that locally supports the execution of a task by a human executor; (2) a Task Pattern Service (TPS) that globally provides information about available task patterns; (3) a PTM Services (PTMS) that locally handles the coordination of the user’s individual TS; (4) a Resource Service (RS) that makes available global resources for individual usage. Regarding these services it must be first clarified which role they play and which functionality they provide. To this end we differentiate internal and external task aspects, i.e., those aspects that are visible for the task requester and those aspects that are only visible for the task executor. The latter correspond to the internal TS implementation whereas the former correspond to TPS making that information public that enables a task requester to identify suitable TS. Personal task repository PTM Service 1. user applies task pattern service

Global repository

New task in inbox

StartSubtaskExecution

Task Pattern Service Task TaskPattern PatternService Service TaskPatter TaskPatter TaskPatternConten TaskPatternConten TaskPattern TaskPatternContent

Task Service Task TaskService Service

Resource Service Resource ResourceService Service

TaskServic TaskServic TaskService

ResourceConte ResourceConte ResourceContent

2. instantiates task service

InitiateSubt InitiateSubt InitiateSubTask Execution

5. user requests resource

Figure 1: PBTM System Architecture

4. User initiates sub-task

3. user modifies task data TaskDataModificat TaskDataModificat TaskDataModification PreSubtaskExecut PreSubtaskExecut PreSubTask Execution

Riss U.V., Grebner O.: Service-Oriented Task Management

357

While local services operate on the Personal Task Repository (PTR) global services operate on the Global Repository (GR) as described in Figure 1. The process starts with a task requester who looks for a suitable pattern for a specific task. To this end the task requester consults the GR via the corresponding local TS to retrieve a suitable TPS, examining the supplied descriptions of service functions, input, and output. After a TPS has been chosen and initiated by the task requester, the TPS identifies a task executor (assisted by the requester or automatically) and initiates a TS running on his or her PTR. The executors, who have to accept a task request, find it in their task inbox after acceptance and further interact with the respective TS. The TS is endowed with a local instance of the task pattern, which is provided by the TPS, and guides the executor through the sub-tasks that constitute the task. Nevertheless the executors are free to change the local pattern according to their situation, by creating new or deleting existing sub-tasks. With respect to these sub-tasks the executor becomes a task requester and the process is repeated in the same way. Naturally not all tasks are decomposed into sub-tasks. Moreover, during the execution of a task the executor can request additional resources via the RS which checks their availability before it assigns them to the executor. The GR takes the role of the registry as part of the WS Framework. The identification of suitable templates resembles the identification of appropriate WS. TPS and TS encapsulate the internal execution of a task, only supplying that information to the requester which is necessary to supervise the execution of the task. The details are only visible to the executor. A question that might arise at this point is whether there is a one-to-one correspondence between tasks and services. We think that a service should be open to support several related tasks. A typical situation of this kind occurs if tasks share a common context that is not directly related to a superior (requesting) task but only locally relevant. For example, we can regard the case of a task concerning travel planning. It might include a flight reservation as well as hotel booking. Obviously both are interrelated but the interplay of both is not necessarily relevant for the task requester who only expects that they fit together. In this case both sub-tasks should be offered as functions of the same service due to their close interrelation, although they refer to different goals and thus describe different tasks since, i.e., they do not necessarily depend on each other. In this way services cannot only represent single tasks but also collections of tasks related to a common context.

References [Erl 05] Erl, T.: Service-Oriented Architecture. PTR, Upper Saddle River, NJ (2005). [Grebner 06] Grebner, O.: Service-oriented task management. Diploma thesis, Department of Business Information Systems, Darmstadt University of Technology, Germany (2006). [Jablonski and Bussler 96] S. Jablonski and C. Bussler. Workflow Management: Modeling Concepts, Architecture, and Implementation. Intern. Thomson Computer Press, London (1996). [Meng et al. 05] Meng, J.; Su, Y. W.; Lam, H.; Helal, A.; Xian, J.; Liu, X.; Yang, S.: “DynaFlow: A Dynamic Inter-Organizational Workflow Management System”; Int. Journal of Business Process Integration and Management (IJBPIM) 1 (2), (2005) to appear.

358

Riss U.V., Grebner O.: Service-Oriented Task Management

[Riss et al. 05] Riss, U.V.; Rickayzen, A.; Maus, H.; Aalst, W. M. P. v. d.: Challenges for Business Process and Task Management. J.UKM 0 (2), (2005) 77-100. [Soares et al. 00] Soares, A.L.; Azevedo, A.L.; de Sousa, J.P.: Distributed planning and control systems for the virtual enterprise: organizational requirements and development life-cycle, Journal of Intelligent Manufacturing 11 (3), (2000) 253-270. [Swenson 05] Swenson, K. D.: ASAP / WF-XML 2.0 Cookbook – Updated. In: L. Fischer: Workflow Handbook 2005. Future Strategies Inc., Lighthouse Point, FL (2005), 257-280.