A Platform to Support Decentralized and Dynamically Distributed P2P Composite OWL-S Service Execution

Transcription

1 Proceedings of the 2nd workshop on Middleware for Service Oriented Computing (MW4SOC), collocated with 8th International Middleware Conference, Newport Beach, CA, US, 2007/11 A Platform to Support Decentralized and Dynamically Distributed P2P Composite OWL-S Service Execution Thorsten Möller and Heiko Schuldt Databases and Information Systems Group University of Basel Bernoullistrasse Basel, Switzerland {thorsten.moeller,heiko.schuldt}@unibas.ch ABSTRACT In a large variety of applications, it is increasingly important to provide application functionality in a modular way by means of (Web) services. At the same time, pre-defined applications are no longer suitable to cope with the high functional dynamics that can be found in novel e-business, e-health, and e-science applications. In contrast, dynamic application creation, i.e., applications that are assembled ad hoc by service composition and usually instantiated very few times, are more and more becoming prevalent. From a systems point of view, large scale application environments like the Internet create scalability requirements towards distributed execution of composite (Web) services which go beyond the traditional non-distributed approach to manage composite services. The contribution of this paper is threefold. First, we present a novel approach that combines those aspects by using different technologies in a distributed environment to dynamically distribute composite service execution in situations where it is beneficial or required. Second, the approach considers semantic annotation of services to facilitate new possibilities for data and service co-ordination. Third, the approach also incorporates the interfaces needed to integrate service execution with semantic service composition planners to allow for dynamic forward failure recovery by contingency service re-planning. These concepts are currently developed on the basis of the peer-to-peer platform OSIRIS NEXT which supports dynamically distributed and decentralized execution of composite semantic services that are described based on OWL-S. Categories and Subject Descriptors H.4.0 [Information Systems Applications]: General Keywords Process Management, Semantic Service, OWL-S, P2P. The work presented in this paper is supported by the EU in the 6 th Framework Program within the STREP CASCOM (Context-Aware Business Application Service Co-ordination in Mobile Computing Environments), contract no Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. MW4SOC 07, November 26, 2007 Newport Beach, CA, USA Copyright 2007 ACM ISBN /07/11...$ INTRODUCTION Service-oriented computing emerged from the motivation to encapsulate functionality and make it available in a well-defined way by providing standardized interfaces for access and description. Today, there are mature technologies for both standardized service access (e.g., SOAP) and operational description (e.g., WSDL). A closely connected research area studies composition of single services into composite services or processes 1 to realize (complex) workflows. Process management has developed mature solutions that allow describing processes in a formalized way (e.g., WS- BPEL) as well as methods for reliable execution in both local and distributed settings. However, traditional approaches to service composition and execution tend to focus on (i) execution in local, non-dynamic environments where distribution and scalability are not of primary concern and (ii) pre-defined applications prevail so that process design is mostly done by human process designers rather than automated composition. Although the manual creation can be supported by process design tools, it impedes further automation. For instance, it can hardly cope with large scale and highly dynamic service environments where new service types are defined frequently, or existing ones change. Also, manual design has to anticipate failure situations and define appropriate handling beforehand. A striking aspect of future e-business, e-health, and e-science applications is increasing functional dynamics. In addition to predefined applications, also applications created ad hoc are increasingly gaining importance. They are dynamically built upon available services that can be easily combined and used in a reliable way within inherently distributed environments like the Internet. At this point, semantic technologies inevitably become necessary since they provide the means to formally express what is needed and match this against what is offered by a service. In particular, semantic description languages (e.g., OWL) are the basis to further advance flexible dynamic discovery, composition, and execution of services, targeting dynamic large-scale distributed environments. In this paper we concentrate on the aspect execution of composite semantic Web Services that are formally described by OWL- S [6] and WSDL [5]. We present a novel approach which is (i) targeted to large-scale Web service environments where scalability is a fundamental requirement. Instead of using a single execution engine, execution of a composite service can be (ii) dynamically distributed among a set of available execution peers, that is, it can migrate from one peer to another. Rather than a migration by default, this happens only in situations where it is beneficial or required. The criteria that assess when migration takes place are based on (non-functional) properties and metadata to cost op- 1 Throughout the paper we use the terms composite service and process synonymously.

2 timize the overall execution procedure. This optimization is able to take into account infrastructure level as well as application level attributes. We introduce a simple generic cost model for describing whether or not migration is beneficial. While having dynamic distribution, (iii) execution does not require any centralized supervision and was developed to happen autonomously in a decentralized way. This gives great flexibility and facilitates a high degree of scalability. Finally, we aim at improving traditional approaches to service failure recovery by the possibility for close integration between semantic service composition planners and our execution platform. This provides the means to (iv) handle service failure situations during execution by on-line contingency service re-planning. The paper is organized as follows. In Section 2 we present a sample e-health application scenario that motivates our approach to distributed execution of processes composed of semantically enriched services. Section 3 introduces OWL-S, a standard for semantic service description. In Section 4 we introduce and discuss our approach and the platform that we have developed. Section 5 presents preliminary experiments and results. Finally, Section 6 reviews related work and Section 7 concludes. 2. A SAMPLE E-HEALTH APPLICATION EMERGENCY ASSISTANCE In what follows, we present an e-health application scenario that motivates the platform and its methods that we have developed. It has been implemented in the context of the EU-funded project CASCOM, together with partners from the healthcare domain. We consider people traveling abroad for business or holidays and which face emergency situations regarding their own health condition, i.e., they need medical emergency assistance. By using a software environment pre-installed on a mobile device (e.g., smart phone) they can deal with this situation and quickly request medical assistance. Specialized services must be discovered and invoked that provide assistance in directing them to a local healthcare institution or to request a local ambulance. Subsequently, emergency physicians in a local hospital or even in an ambulance can use other specialized services on their mobile devices to access information from health records of the patient, probably stored in the patient s home country. This helps to prepare for upcoming medical cases, to learn about the medical history of a patient, or to avoid redundant and/or unnecessary examinations. In case of patient repatriation (transport to their home country), yet again specialized services will have to be used. All participants of this scenario are in the need to gather information that can be provided by services. In a real world setting the number of users very likely rises up to many thousands. Also, it is not feasible to know about services beforehand because of their number and variety. Instead, they must be discovered dynamically based on queries against directories which express exactly the semantics of what is needed. Only then they can be further used. A huge number of available services also implies enormous diversity of them, not only in terms of functionality but also in terms of resource consumption, more generally, in terms of costs: Some will be more computing and/or data intensive than others; depending on the location of service requester and provider, communication paths might offer different characteristics; service providers that offer similar services might charge different costs for using them. Finally, dynamic service composition needs to be done whenever complex use cases can be automated by combining a set of services into new composite services. In the emergency assistance scenario, emergency physicians are Figure 1: Sample Composite Service to retrieve Patient Health Record Documents given access to existing medical patient records that are stored by other medical institutions. Healthcare institutions are more and more going to provide access to patient data by means of services. An example for this trend is the health@net [20] project which aims at creating a cross-institutional health care network and develops a Web Service based infrastructure for integration and electronic transmission of medical patient data. Figure 1 depicts the composite service that is created automatically by a composition planner which is in charge of process specification. Three different services, ordered sequentially, gather all available medical documents for a certain patient. As input parameter it takes patient properties like name, social security number, and so forth. The first service F indp atient (FP) returns a patient identifier that is used by the second service QueryP atientrecord (QPR) to return document identifiers of all documents that exist about this patient. Eventually, this set is taken by the last service GetDocument (GD) to gather and return all documents. 3. SEMANTIC SERVICE DESCRIPTION The driving objective behind semantic aware description of Web services is to make semantics of data understandable to computers, thus, creating a significant potential for advanced automation. Two of the main efforts in the semantic web services domain are OWL- S [6] (formerly known as DAML-S) and WSMO [9]. OWL-S formal specification comes as a set of layered OWL ontologies containing three primary parts: the Service Profile, Process Model, and Grounding. The service profile presents what the service does in terms of its capabilities. The main part is the functional description consisting of the Inputs, Outputs, Preconditions, and Effects. The profile is used mainly for advertising, discovery, and composition purposes. The process model describes how the service is used by specifying a control and data flow. The elementary, indivisible operation is called Atomic Process, which represents exactly one service invocation. On the other hand, a Composite Process is decomposable into other (non-composite or composite) processes; their components can be specified by using control constructs such as Sequence, Split-Join, If-Then-Else, etc. Both service profile and process model are thought of as abstract characterizations of a service. In order to actually interact with a service it must be bound to at least one Grounding. The latter provides the necessary details of how to embody this interaction in terms of message format, transport protocol, and addressing. Several different types of grounding have been devised. The most widely used one, which is included in the OWL-S release, employs WSDL 1.1. More recent work discusses grounding based on WSDL 2.0 and relations to SAWSDL [10]. 4. THE OSIRIS NEXT PLATFORM Our vision of having a distributed and decentralized process management system that also exploits semantic services has led to the development of the novel platform OSIRIS NEXT. It is the continuation of research work that builds on many ideas of the OSIRIS system [16]. In recent works reliable data stream management has also been incorporated into it [4].

3 4.1 Properties and Basic Assumptions to Distributed Process Execution In general, composite service execution comprises invocation and co-ordination of several services according to control and data flow dependencies. Usually, this is done by a dedicated software component subsequently named execution engine. Applied to OWL-S, the execution engine goes through the process model while respecting its operational semantics and invoking individual services which are represented by atomic processes. So far, this is independent of the fact whether it is done in distributed or nondistributed way. While in the non-distributed setting this would be done solely by one execution engine, the responsibility to orchestrate the execution is supposed to be shared among a set of cooperating engines in a distributed setting. If the underlying method to carry out this procedure does not require any global supervision it is called decentralized. In the following we list general assumptions of our approach. The OWL-S process model defines a partial precedence order on the containing atomic processes, i.e., it specifies the regular order in which invocations are to be done. An invocation can only be done when all its pre-ordered invocations have successfully finished and when the conditions on its invocation are fulfilled. Services are stateless. They never have to remember anything beyond interaction. Execution state (i.e., intermediate results) is solely stored by the execution system, as part of the process instance. Data flow is defined in terms of mappings from the execution state to the service request parameter values, and back from the response values to execution state. Currently, we assume that stateless SOAP based Web services are used. However, REST based Web services are an option that we aim to support in the future by devising a dedicated OWL-S grounding for REST. We consider the crash failure model, which means that components such as services and machines may fail by prematurely halting their execution. Communication related failures are subsumed under service failures. 4.2 Platform Architecture The OSIRIS NEXT platform combines a rich set of features. Originally based on the hyperdatabase vision [15], ideas from process management, peer-to-peer networks, database technology, and Grid infrastructures have been combined. In short, it is a scalable and distributed yet decentralized process management system. At its bottom layer the OSIRIS NEXT platform essentially represents a peer-to-peer message-oriented middleware. On top of this it builds an integrated and lightweight component framework. The component framework allows to implement and run custom components each delivering a pre-defined functionality and able to communicate with other (remote) components. The messaging layer basically realizes (i) the publish/subscribe messaging paradigm as well as (ii) addressing of specific receivers, i.e., components. Furthermore, it incorporates advanced concepts such as eager or lazy data replication, and data freshness properties. Finally, the internal design of the platform is strictly multithreaded. Internal details of each peer are described in Section Strategy for Dynamic Execution Distribution and Decentralization Distributed execution of composite services invariably requires a strategy to organize and co-ordinate how participating peers share this task. Such a strategy is built upon three core properties: First, it includes how to divide the composite service into sections which Allowed Not Allowed Void Sequence Split If-Then-Else For-Each Split+Join Choice Repeat-While Repeat-Until Any-Order Table 1: Execution migration inside OWL-S control constructs can be executed by different execution peers. Within a section, execution is done by the same peer. Second, it defines where and when to distribute those sections to different execution peers. Finally, it defines a mechanism to co-ordinate control among the participating peers to guarantee consistent execution. Altogether they imply the way execution will be actually done at runtime. The question how a composite service can be divided into sections can be answered by analyzing the different control structures of the process model of OWL-S. As a first approximation, one could use the smallest granularity for sections, that is, equal to the atomic processes. However, this might become problematic when taking into account the control structures Split and Split+Join. At runtime, both constructs are supposed to span concurrent execution of their subsequent process constructs. Because of the independent and parallel handling of them more effort would be necessary to create sections that span all parallel branches. For the time being, we decided to disallow creating sections inside parallel branches. For all other control structures no such restrictions are imposed (cf. Table 1). Yet another important aspect for categorization of execution strategies relates to whether an execution peer and the (Web) service are tightly integrated/coupled or not the latter one we name remote coupling. By tightly integrated we mean that a execution peer basically wraps one or more services, that is, both run on the same machine, probably even in the same operating system process. This is to optimize invocation by bypassing the overhead of the whole Web services stack by performing direct programmatic calls. Furthermore, this tight integration mostly comes along with the intention that a execution peer wraps a fixed set of services which does not change. As opposed to tight integration, remote coupling means that the execution peer and the (Web) service provider are disjoint, that is, the invocation is done in the standard way (e.g., via HTTP over SOAP). Figure 2 illustrates the course of the dynamically-distributed and decentralized execution strategy. It is based on our sample composite service presented in Section 2 containing a sequence of three Web service invocations. It is also assumed that the composite service is split up into sections equal to the atomic services inside. The strategy works as follows: a. The client submits the (valid) OWL-S composite service description together with the input data to one available execution peer, SEC 1 in this case (step 1 in Figure 2). b. SEC 1 parses the service description and initializes a new execution state where intermediate results will be stored. c. A decision step follows to determine whether execution of the next section should be made by this peer or whether the execution should migrate to another peer and continue there. In the example we assume that execution can stay at SEC 1. Consequently, it starts the first section which maps to service F P (2). d. The same decision step is repeated for each section. e. In the example we assume that after invocation of QP R by SEC 1 (3) execution migrates to another peer, say SEC 2 (4).

4 Figure 2: Execution Strategy based on the Sample Composite Service of Figure 1 This is accomplished by serializing/transferring the execution state. f. Finally, after invocation of GD (5) the last section has finished and the result is returned to the client by SEC 2 (6). A general observation is that migration from one peer to another comes at the expense of an increased communication effort compared to no migration because the current execution state must be transferred to the new peer. On the other hand, even with this overhead the overall situation can improve provided that the execution of the remaining part of the composite service can be done in a more efficient way on the new peer. To make this more precise, we model this by the following function B i that allows to estimate the benefit gained from a transfer of a process instance i. Let P be the set of available peers and p c, p n P the current execution peer resp. a new execution peer (c n). B i : P P R B i(p c, p n ) = cost x(c p c) (cost x(c p n) + cost m(p c, p n )) B i(p c, p n ) is based on two functions, cost x and cost m. The function cost x gets as input a context information set c p c (resp. c p n) representing information about the environment of the current peer resp. a new peer. It estimates execution costs of the remaining part of the composite service. In practice, the context information set might include various information deriving from the infrastructure as well as from the application domain. For instance, infrastructure related information can be available computation and memory resources, load measurements, and other runtime related information. Application related information might provide metadata about services like non-functional properties and requirements describing, for instance, whether a service is memory, data, or computing intensive. The function cost m faces the (communication) costs for migrating execution from p c to p n. In practice, the value of this function mostly depends on the network topology and the overhead to serialize and de-serialize the current execution state. With cost x > 0 and cost m > 0, the overall result of B i can be characterized as follows. B i < 0 : execution would adverse at the new peer; B i = 0 : execution can continue at either places; B i > 0 : execution would benefit from a migration to the new peer. In order to find the most suitable successor peer p n, the maximum benefit over all existing peers needs to be determined. p n = max{ p P \p c : B i(p c, p)} The approach is able to cope with external failure situations of services or network failures but not with crash situations of the current execution peer itself. Two possibilities exist to overcome this problem: Either the current execution state is made persistent, or it is replicated online to another execution peer. Whereas the first method is only appropriate if the peer gets rebooted immediately afterwards and recovers/restarts the interrupted execution, the second solution is more suited to minimize the interruption delay since execution can be immediately overtaken by the peer which has the replicated execution state. However, in the latter case it needs to be guaranteed that recovery of a failed peer does not lead to duplication of process instances, i.e., a peer that recovered needs to decide whether control is taken over by another peer. Despite of its simplicity, this approach can easily support dynamic adaptation to changing (service) environments like it is the case in the application scenario that we have outlined in Section 2. Combined with the fact that distribution only takes place if beneficial or required, it can balance/optimize overall system behavior. 4.4 Advanced Client Interaction to support Forward Failure Recovery In general, execution of a composite service can be triggered by any client, independent of whether is was created by automated composition or not. The client would issue the composite service description together with actual input data and (asynchronously) await the result. During execution any sub service invocation might fail, for instance, if the service is temporarily not available. To recover a consistent state in such a situation classical approaches consider to cancel or rollback service invocations that were already made; provided that services offer undo functionality. Afterwards, the rollback would be propagated to the client, i.e., up to the application level. It would be a matter of the application on the client side to handle the failed execution of the composite service. In our approach we want to support a more advanced and systemsupported forward handling that becomes possible based on recent advances to dynamic service composition planning and the expressiveness of OWL-S. First, a close integration with composition planners is needed. We consider that a dedicated planner acts as the client. It issues ad hoc created composite services to any peer that is available together with the actual inputs. In case of service failure situations detected by the current execution peer it temporarily suspends execution and notifies the planner by requesting contingency re-planning, i.e., forward recovery by trying to employ equivalent services that eventually lead to the same goal. To accomplish this the planner requires information about the effects of the service invocations that have been already made. The OWL-S service profile and process model provides elementary support as it allows to specify such effects (post-conditions) of services based on logic description languages like SWRL. The current execution peer has to collect the effect(s) of service invocations that were already done successfully and send them to the planner. If the service that failed has specified a failure effect within its OWL-S description it includes this effect as well. With this knowledge about the changes of the state of the world the planner would be able to create a contingency plan provided that equivalent services exist, and which are known to the planner. Only in case the planner did not succeed, the execution would have to be aborted. The resulting interaction pattern between the client planner and execution peer refers to extended asynchronous request/reply conversations for which we have specified and implemented a dedicated protocol [18]. This protocol is compatible with the dynamic distribution approach, meaning that different execution peers might be involved in the message conversation with the client during execution. If a client is used that does not implement re-planning functionality it simply has to denote this in the initial request. In a problem situation the execution will be aborted immediately and a failure message is sent back. 4.5 Current Implementation Figure 3(a) illustrates the internal architecture of a peer with respect to message passing and the component framework. On

5 Figure 3: Internal Architecture of a Peer the highest level, each peer can run any number of Components which provide either system functionality or application functionality (probably provided by third parties). The OWL-S execution engine is implemented as such a component (cf. Figure 3(b)). A lightweight component life cycle controls startup, re-loading and unloading of them. Each component can interact with any other component at any peer either by direct asynchronous message passing or by a publish/subscribe interaction pattern. Message Handlers implement the functionality that is associated to certain types of messages. Each handler is placed in a thread pool and becomes active as soon as the Work Queue processes a message whose type is associated with it. Newly produced messages by a handler will be enqueued for delivery to the dedicated message routing component Horus which runs at each peer. The Transport Layer forms the lowest part of each peer. It is responsible for en/decoding of messages and delivering them to other peers using arbitrary transmission protocols. Address resolution is also done at this level, thus, allowing to integrate typical P2P network overlay techniques. For flexibility reasons the transport layer is exchangeable, not limited to only one per peer, and allows to configure arbitrary message codecs. The platform is an ongoing effort and implemented in Java. It can be deployed in two ways: stand-alone and agent-based. In the stand-alone mode it is used as is, that is, it is not embedded into another system. On the other hand, the agent based mode is an addon and was created to deploy the system in the JADE agent platform [3]. In short, in the agent-based mode a peer instance represents itself as an agent to the outside and all interactions take place using standardized FIPA-ACL messages [7], accomplished by a dedicated ACL transport layer. Even mixed deployments are possible since internal communication between peers abstracts from the actual transport layer that is used. The processing of OWL-S respectively OWL is based on the open source Mindswap OWL-S API [19]. For invocation of Web services that use SOAP (over HTTP) we use the open source Web service stack implementation Apache AXIS. 5. FIRST EXPERIMENTAL EVALUATION In a first series of tests of the OSIRIS NEXT platform, we addressed the characteristics of the internal queued thread model of a peer on increasing load ( micro-benchmarking ). In the experiment depicted in Figure 4 we measured the overall execution time as a function of concurrent execution requests. The test setup is as follows. We used standard DualCore Intel Pentium based machines (3.4GHz, 2GB RAM) connected to the Internet via 1Gb/s network. We decided to apply the benchmark in the public Internet environment to represent practical influences as well. Therefore, an exemplary composite service DictionaryTranslator was used, built upon a sequence of three real Web services: First, Figure 4: Micro-benchmarking: Service Execution Time with Increasing Load a given term is used as input and translated to English from another language using Babelfish Translator service. Afterwards, the translated term is looked up using Online English Dictionary service, and finally the term definition is translated back to the original language. 2 A client peer that was running 1 to 40 threads (step size 5) issued the service description using varying input terms to the execution peer. Each group was repeated ten times. The mean value shows that the system nearly scales ideally up to 35 concurrent executions. The increase afterwards is not necessarily caused by the system but can also be a matter of the network and/or the used Web services. To unambiguously detect the internal scaling saturation point it seems advisable to also apply the benchmark in a more controlled environment using synthetic Web services that do not become a limiting factor. The visible outliers and variances even for this modest composite service caused by the dynamics of the Internet environment motivate the demand for adaptive while open solutions as presented in this paper. 6. RELATED WORK To our best knowledge, a scalable while distributed solution towards an execution platform for OWL-S based semantic services is not available yet. Only a non-distributed approach has been proposed in [12]. Similarly, a system that enables creation and execution of semantic Web services based on WSMO has been presented in [8]. When abstracting from semantic-aware information processing, service execution is a widely addressed area in both industry and research. By analyzing the concepts behind decentralization and distribution of composite service execution which have been proposed in [11], [22], and the original approach of the OSIRIS platform [17] one can notice that they are well suited for frequent reinstantiation of composite services. Also, they imply a tight integration of execution peers and service providers, i.e., services are actually part of the architecture by deploying additional software layers on them. In case of ad hoc created composite services which are probably instantiated only once, the initial distribution of meta data to subsequently involved peers as it is common to all the aforementioned approaches is a rather limiting factor compared to the fact that it is not required in our approach. Furthermore, they can not support situations when it is impossible to deploy additional software layers at service provider side. From an organi- 2 The OSIRIS NEXT platform has been successfully evaluated by emergency physicians in a deployment that makes use of productive semantic Web services provided by a healthcare institution. For obvious reasons, these services are not available for performance evaluations.

6 zational point of view, we believe that our approach is better suited for cross-organizational use since additional software layers at service provider side are not required. The IBM Websphere Business Process Choreographer [21] allows distributing process execution across several process engines which all, in turn, use the same central instance database. Another approach that considers execution of processes within a P2P community of individual service providers has been proposed in [1]. Contributions that also follow a distributed approach and especially address structural changes of running workflow instances by forward recovery can be found in [14]. The issue of whether dynamic migration of execution state from one peer to another justifies the additional (communication) effort that it creates has been analyzed in [2]. It is shown that it is not useful as a reaction to overload situations of the communication system and/or the current peer since it would add even more load to them. A survey of state of the art methods for creating fault-tolerant execution in the agent-oriented research domain can be found in [13]. 7. CONCLUSIONS AND FUTURE WORK In this paper we have presented our approach to reliable and scalable execution of composite semantic services described by OWL- S. We can achieve high flexibility with respect to changing service environments by making the execution process dynamically distributed across a arbitrary set of available peers. We provide built-in scalability support at two levels: first at a micro level by a multi-threaded approach that allows each peer to handle multiple execution requests concurrently. Second, at a macro or infrastructure level by the possibility to dynamically migrate execution from one peer to another. Reliability can also be supported at two levels. First, by the possibility to handle external failure situations by the migration of process instances to another peer and second, by integration with dynamic contingency service re-planning. The system does not make a difference in how composite services were created (ad hoc vs. pre-defined) but offers efficient integration with composition planners for re-planning purposes. The development of the OSIRIS NEXT platform is an ongoing effort. Future activities will focus on the development of practical migration strategies that incorporate various (runtime) meta data and quality of service (QoS) attributes that allow to efficiently determine best suited peers for migration. Furthermore, the interfacing with service composition planners for dynamic contingency replanning is an area that still deserves a more comprehensive examination. In turn this will help to improve failure support in OWL-S. 8. REFERENCES [1] A. Dogac et al. A workflow system through cooperating agents for control and document flow over the internet. In Proc. of the 7 th Int l Conf. on Cooperative Information Systems, pages , Eilat, Israel, [2] T. Bauer and M. Reichert. Dynamic Change of Server Assignments in Distributed Workflow Management Systems. In Proc. of the 6 th Int l Conf. on Enterprise Information Systems, pages 91 98, Porto, Portugal, [3] F. Bellifemine, A. Poggi, and G. Rimassa. Developing multi-agent systems with a FIPA-compliant agent framework. Software-Practice and Experience, 2(31): , [4] G. Brettlecker, H. Schuldt, and H.-J. Schek. Efficient and Coordinated Checkpointing for Reliable Distributed Data Stream Management. In Proc. of the 10th Conf. on Advances in Databases and Information Systems, pages , Thessaloniki, Greece, [5] E. Christensen, F. Curbera, G. Meredith, and S. Weerawarana. Web Services Description Language (WSDL) [6] D. Martin et al. OWL-S: Semantic Markup for Web Services [7] Foundation for Intelligent Physical Agents. FIPA ACL message structure. SC00061, Geneva, Switzerland, [8] A. Haller, E. Cimpian, A. Mocan, E. Oren, and C. Bussler. WSMX - A Semantic Service-Oriented Architecture. In Proc. Int l Conf. on Web Services, Orlando, FL, USA, [9] H. Lausen, A. Polleres, and D. Roman. Web Service Modeling Ontology (WSMO) [10] D. Martin, M. Paolucci, and M. Wagner. Towards Semantic Annotations of Web Services: OWL-S from the SAWSDL Perspective, OWL-S: Experiences and Directions - workshop at 4th European Semantic Web Conf. [11] M. G. Nanda, S. Chandra, and V. Sarkar. Decentralizing Execution of Composite Web Services. In Proc. of the 19th annual ACM SIGPLAN conf. on OO programming, systems, languages, and applications, pages , New York, NY, USA, ACM Press. [12] M. Paolucci, A. Ankolekar, N. Srinivasan, and K. Sycara. The DAML-S virtual machine. In Int l Semantic Web Conf., volume 2879, pages Springer, [13] W. Qu, H. Shen, and X. Defago. A Survey of Mobile Agent-Based Fault-Tolerant Technology. Parallel and Distributed Computing, Applications and Technologies, 0: , [14] S. Rinderle, S. Bassil, and M. Reichert. A Framework for Semantic Recovery Strategies in Case of Process Activity Failures. In Proc. 8 th Int l Conf. on Enterprise Information Systems, Paphos, Cyprus, [15] H.-J. Schek, H. Schuldt, C. Schuler, and R. Weber. Infrastructure for Information Spaces. In Advances in Databases and Information Systems, Proc. 6th East- European Symp., pages 23 36, Bratislava, Slovakia, [16] C. Schuler, C. Türker, H.-J. Schek, R. Weber, and H. Schuldt. Scalable peer-to-peer process management. Int l Journal of Business Process Integration and Management, [17] C. Schuler, R. Weber, H. Schuldt, and H.-J. Schek. Scalable Peer-to-Peer Process Management - The OSIRIS Approach. In Proc. of the 2 nd Int l Conf. on Web Services, pages 26 34, San Diego, CA, USA, IEEE. [18] M. Schumacher, H. Helin, and H. Schuldt, editors. CASCOM: Intelligent Service Coordination in the Semantic Web. Whitestein, to appear. [19] E. Sirin. OWL-S API project website. [20] T. Schabetsberger et al. From a paper-based transmission of discharge summaries to electronic communication in health care regions. Int l Journal of Medical Informatics, 3-4(75): , [21] IBM WebSphere Business Process Choreopgrapher. websphere/zones/was/wpc.html, [22] X. Ye. Towards a reliable distributed web service execution engine. In Proc. of the IEEE Int l Conf. on Web Services, pages , Washington, DC, USA, IEEE.