Context-aware Secure Service Composition Planning and Execution on E-Health Environments* António Lopes1, Paulo Costa1, Federico Bergenti2, Matthias Klusch3, Bastian Blankenburg3, Thorsten Möller4, Heiko Schuldt4 1
“We, the Body and the Mind” Research Lab of ADETTI-ISCTE Av. das Forças Armadas, Ed. ISCTE, 1600-082 Lisboa, Portugal
[email protected],
[email protected] 2
FRAMeTech S.R.L. Via San Leonardo 1, 43100 Parma, Italy
[email protected] 3
German Research Center for Artificial Intelligence 66123 Saarbruecken, Germany {klusch, blankenb}@dfki.de
4
University of Basel – Database and Information Systems Group Bernoullistrasse 16, 4056 Basel, Switzerland
[email protected],
[email protected]
Abstract: Emergency Health-Care based scenarios provide the motivation to develop supporting technologies for dealing with situations where people need medical assistance because of a sudden disease or emergency. The innovative combination of intelligent agent technology, semantic Web services, peer-to-peer, and mobile computing for intelligent peer-to-peer mobile service environments is the corner stone of the CASCOM project, which aims at providing a value-added support for business services for mobile workers and users across mobile and fixed networks, especially for e-Health environments. In this paper, we describe the technical approach developed in the CASCOM project for the context-aware secure composition planning and execution of Semantic Web Services.
1 Introduction CASCOM [H05] project’s mission is to address research challenges by performing innovative research towards supportive infrastructure for business application services for mobile workers and users across mobile and fixed networks. Its driving vision is that ubiquitous business application services are flexibly coordinated and pervasively provided to mobile workers and users by intelligent agents in dynamically changing *
This work has been supported in part by the European Commission under the project grant FP6-IST-511632CASCOM.
179
179
contexts of open, large-scale, and pervasive environments. To this end, the project uses a technical approach that combines agent technology, Semantic Web Services coordination, P2P, and mobile computing for intelligent peer-to-peer (IP2P) mobile service environments. Among the great amount of challenges that this vision presents, the context-aware secure composition planning and execution of Semantic Web Services is, definitely, one of the most interesting and difficult to address. In this paper, we describe the technical approach used to address this challenge, which is organized as follows: in section 2 we describe motivating use case scenarios regarding e-Health environments; section 3 describes the composition planning and execution environment developed in the project; section 4 describes the generic context framework developed in the project to provide context-aware capabilities to all entities in the environment; section 5 addresses the security issues by describing the approach used in the project; finally in section 6, we provide a brief conclusion and comparison of our approach with similar projects.
2 e-Health Use Case Scenario In order to gain more deep understanding of requirements, behavior, and needs of mobile users and workers, the CASCOM project has developed several use case scenarios. One of those use case scenarios is the Emergency Healthcare Scenario, which depicts two stories in which different people in different countries face emergency situations regarding their own health condition using the CASCOM software environment to deal with them and quickly find an adequate solution. Currently, these sorts of episodes are neither tackled nor realized in this form in practice and no software system is presently widespread in use to address them. In the first story, a man on a business trip suddenly observes serious ailments with his stomach unknown to him. Using the CASCOM software installed in his smart phone he is directed to a sophisticated healthcare institution where the CASCOM infrastructure is also available, which allows for accessing information from the record of this person stored in his home country in order to avoid redundant and unnecessary examinations and even to negotiate on the coverage of costs with his health insurance. In the second story, tourists from Finland are having summer vacation abroad. During the trip, one of them seriously suffers from pain in the upper part of her body. Although she has installed our system to her PDA, our infrastructure is not fully supported at the present location, which changes the story significantly from the first one. However, even in this case, the CASCOM system proves to be helpful. Essentially, the availability of our system allows the patient for instance to contact another physician for a second opinion. In addition, a service provider in the home country can be contacted for organizing the transfer back home. This kind of scenarios involve complex requirements, which raise the need for on-demand initiation, co-ordination, and supervision of various activities represented either through persons, or non-human actors (i.e., agents and services).
180
180
3 Composition Planning and Execution 3.1 Service composition planning with OWLS-XPlan OWLS-XPlan consists of several modules for pre-processing and planning. It takes a set of available OWL-S services, a domain description and a planning query as input. The domain description and the planning query contain OWL individuals (facts) which are true initially or are to be achieved by the plan, respectively. They also contain the necessary OWL ontologies. OWLS-XPlan then returns a plan sequence, i.e. a composed service, which satisfies the planning query. For this purpose, it first converts the domain ontology and service descriptions in OWL and OWL-S, respectively, to an equivalent PDDL 2.1 problem and domain descriptions using the OWLS2PDDL converter. The domain description contains the definition of all types, predicates and actions, whereas the problem description includes all objects, the initial state, and the goal state. Both descriptions are then used by the AI planner XPlan to create a plan (representing a composed Web-Service) in PDDL that solves the given problem in the actual domain. For reasons of convenience, we developed a XML dialect of PDDL, called PDDXML that simplifies parsing, reading, and communicating PDDL descriptions using SOAP. We also developed a module to convert the PDDXML plan description to an OWL-S process model, making it possible to seamlessly integrate OWLS-XPlan into a purely OWL-S based system. The XPlan system consists of one XML parsing module, and following pre-processing modules. First, required data structures for planning are created and filled, followed by the generation of the initial connectivity graph and goal agenda. The latter two actions are interleaved with replanning. The core (re-)planning modules concern the heuristically relaxed graph-plan generation and enforced hill-climbing search (cf. Figure 1). Input: PDDXML problem description
Building the internal data structures
XML Parser PDDXML domain description
Result:
• Preparing the input data • Creating type-hierarchies • Filtering relevant operator instances
Data Preprocessing
Generation of a dependency graph
Connectivity Graph Generation
Generation of a reachable goal sequence
Goal Agenda Generation
Preprocessing
Enforced hill Climbing search
PDDXML plan description
heuristics:Relaxed Graphplan Generation • Generation of a relaxed planning graph where the operators have no delete lists • Extracting helpful operators
Core (re-)planning
Figure 1 - Architecture of XPlan
181
181
After the domain and problem definitions have been parsed, XPlan compiles the information into memory efficient data structures. A connectivity graph is then generated and efficiently realized by means of a look up table, which contains information about connections between facts and instantiated operators, as well as information about numerical expressions which can be connected to facts. This connectivity graph is maintained during the whole planning process and used for the actual search. In case of a replanning situation, the connectivity graph is adjusted according to the changed new world state. XPlan uses an enforced hill-climbing search method to prune the search space during planning, and a modified version of relaxed graph-planning that allows to use (decomposition) information from hierarchical task networks during the efficient creation of the relaxed planning graph, if required, such as in partially hierarchical domains. Information on the quality of an action (service) is utilized by the local search to decide upon two or more steps that are equally weighted by the used heuristic. In addition, XPlan includes a replanning component which is able to re-adjust outdated plans during execution time. Therefore, the execution engine informs the planning module about changed world states, and the XPlan replanning component decides whether the remaining plan fragment to execute is still valid or whether a re-planning has to be initiated. Figure 2 shows a fragment of the plan description produced by XPlan, i.e., a sequence of actions, which is the composed sequence of corresponding OWL-S services that can be executed by the agent. PDDL 2.1 plan fragment Plan step 0 = First action in plan = First service to execute
Effect of execution: Change of agent & world state
Plan step 1
Figure 2 - Part of plan description in PDDXML
182
182
We implemented XPlan modularly in C++, using the Microsoft MSXML Parser for reading PDDXML definitions and generating plans in XML format. Alternatively, XPlan also provides an interface for direct interchange of planning data without having to use PDDXML as interchange format. If the user wants to have the composition plan a certain degree of quality, an optional OWLS-XPlan module will compute a QoS optimized service execution plan. This is, in essence, accomplished by means of integer linear programming, given set of QoS parameter value bounds, and set of equivalent services with QoS valuation for each service of the original composition plan. Equivalent services are retrieved on request by a contacted service matchmaker. For more details on the service composition planner OWLS-XPlan, we refer the interested reader to [KGS05]. However, once a QoS optimized service execution plan has been created, it has to be consistently executed in a reliable way among the service agents involved. 3.2. Consistent Service Execution Service execution comprises initiation, control, and validation of service invocations, i.e., it is a runtime environment for compound services (processes). A fundamental feature of this runtime environment is that it is able to guarantee certain execution properties like guaranteed termination, correctness, and atomicity – to state the most important ones only. As illustrated in Section 2, the scenario typically involves interaction with several service providers to realize the use cases. As a consequence, the services involved need to be composed dynamically into processes by the service composition planning system (see Section 3.1). Finally, the planned processes will be issued directly for execution. In the following, we describe the structure of the service execution system and the interaction model. The CASCOM service execution is implemented as an autonomous agent – intended to be deployed within the CASCOM agent platform [HPSS06] or the JADE platform – and allows for consistent execution of OWL-S process models. The implementation is based on the OSIRIS process management system [SSTWS05] and was extended to support execution of semantic web services. In particular, the execution system consists of one or more federated execution agents organized in a peer-to-peer manner, meaning that no central execution coordinator is required. To accomplish this, every agent implements a process manager which invokes the services and which coordinates execution basically by forwarding control and data to the next agent(s).
183
183
Figure 3 - Interaction and execution model
As shown in Figure 3, after an OWL-S process model has been planned and submitted (1) the execution first involves decomposing the process model into its atomic execution units (2). An execution unit contains a service invocation s and links to all the services that are the direct successors of s. For failure handling purposes, also information on the predecessors of s is needed. This is important in order to determine the service(s) which need to be compensated (i.e., which effects need to be undone) in case of a failure during process execution. Thus it appears that the units provide execution agents with all information they require to execute a service and to do forward navigation in any case. Furthermore, the explicit distinction between control and data flow enables optimal interaction paths with as less communication efforts between execution agents as possible. The preparation phase finishes with service instance (provider) matchmaking (3) which is done in case an abstract process model was submitted. Concrete service providers will be selected – as per OWL-S terminology the grounding for a service profile is resolved – according to most current QoS parameters like service instance utilisation. This step is instantly followed by spawning the actual service invocations (4). During execution, failures might happen, for example service instances or other infrastructure components might crash. In such a situation, execution cannot terminate or at least cannot continue without some recovery mechanism. In classical transactional systems, this would lead to an abort of the global transaction (i.e., all side effects created so far will be undone or compensated) and some external logic has to decide what to do next. In our novel approach, a crash failure situation does not necessarily end up in the abortion of process execution. After a failure, execution temporarily freezes and a re-planning request will be initiated by forwarding the effects created so far (5) – remember that the original execution goal still holds. Starting from the stop point, the planner now tries to fix the
184
184
problem by searching for an alternative path (6) – usually by employing semantically similar services. In case of success a partial new process will be sent back to the execution (7). Otherwise, if it was not possible to find an alternative path, the execution system receives an abort command and is obligated to rollback the process side effects completely (8). In the first case, execution continues (9) with the new process fragment after replacing the now obsolete remaining process fragment. Finally, when execution has finished, the result will be sent back to the Service Composition Planner Agent (10). In order not to block resources endlessly during on-line re-planning, we use a timeout based approach: In case of no reply until some pre-defined timeout, current execution aborts.
4 Context-Awareness The use of context-aware computing in service oriented programs allows users and applications to communicate in a simpler way making these services more appellative and efficient. The CASCOM context-aware framework supports an approach for ubiquitous computing paradigm to service oriented programs such as Semantic Web Services. The principal of this paradigm is to enhance usability of applications by letting them adapt to conditions that directly affect their operations. When two entities communicate, a great amount of implicit information is never directly transmitted between them. This implicit information is called context and it allows the entities to improve their interaction, providing a shared background in which the meaning of the communicative act becomes grounded in their situation. This is done without overloading the information explicitly conveyed. These benefits can then be passed to the service domain through the use of context and context-aware applications. The CASCOM context-aware framework aims at providing a simple way for accessing, managing and integrating contextual information into the activity of the entities of the environment. Sensors and sensor networks are used to expand application communication with the environment [DAS01]. To simplify the communication between these sensors and the applications the framework offers a generic and easy to use context system architecture. This system uses an infrastructure approach [HL01] allowing every types of applications, including web-services, to access context information. Services and applications can directly access this framework to query the system for context, register for context events or supply context information to the context system, which stores all relevant data in appropriate repositories. The proposed systems’ architecture is presented in Figure 4. This architecture is divided in two levels: the application level, identified by the context interpreter, defines application specific modules that will be implemented by the applications that will use this subsystem; the generic level is responsible for the capture of context information from the sensors and its representation in a uniform way.
185
185
Figure 4 - Context System Architecture
The generic level possesses several interfaces for context query and acquisition, event listening, context storage and sensor communication. The application specific level has a set of application specific components that interpret, aggregate and reason about context. Context-aware applications and services can directly access the context system trough its interfaces. The context system can also be used inside other platforms. In the case of the CASCOM, a service-oriented platform is used. To prove the effectiveness of the presented framework, an application scenario has been defined. This scenario is part of the emergency assistance scenario defined in the CASCOM project. This scenario defines a medical assistance platform based on services that use several components to find, compose and execute these services. Its main purpose is the aggregation of different services with the aid of contextual information, in order to obtain a user determined objective. Each one of the components makes use of context information to improve general performance. The platform works on top of a peer-to-peer based network, where several medical related services can be found.
5 Security The IP2P metaphor that CASCOM advocates, like all new software technologies, comes with inherent security and privacy risks that often go unnoticed to researchers and practitioners that are not specialists of computer security.
186
186
Data confidentiality, integrity, and availability (CIA) [SecPedia] are topics of concern that any approach to security must address. Data confidentiality is upheld when only certain authorized individuals are allowed to view certain pieces of information. Data integrity refers to preventing data from being modified or corrupted. Loss of data integrity can result from a communication failure where data is somehow modified during transit from one location to another. Data integrity also applies to stored data that can be modified or corrupted, intentionally or unintentionally. Data availability refers to keeping data available for access to authorized parties whenever it may be needed. Obviously, the IP2P environment of CASCOM exacerbates these issues because of the fundamental role of availability in the scope of any IP2P network, especially when wireless – and therefore possibly disconnected – nodes are present. Not only data is a security concern, but also the software that deals with it. Within the realm of computer security, the misuse, theft, and unauthorized usage of computing resources is well studied. This concern is of singular importance for IP2P systems. The one and only approach to address these issues in a structured way is to have the possibility to fine control all resources that agents/services use. Unfortunately, this is not possible with nowadays technologies because Java sandboxes are not capable of controlling the access to all resources. For example, no one can forbid an agent to indefinitely busy wait, thus consuming a large amount of CPU cycles. CASCOM platform integrates all best-practice approaches to computer security into a transparent layer within the CASCOM platform. Application developers are not explicitly involved in the security chain and they simply turn security on or off at platform boot time. While we have an established literature to deal with security at lower levels of communication stacks, security at higher levels involves concepts like privacy and trust that are still far from being consolidated. Agents are often capable of acting on behalf of users and they can autonomously take decisions that may involve different users, therefore, they are potentially sources of private and sensitive information. Privacy-awareness is a property of a system that cannot be guaranteed a-posteriori, i.e., there is no way to validate an application from the point of view of privacy. Rather, an a-priori approach must be taken, just like for security. This is the reason why we need to explicitly embed abstractions related to privacy into CASCOM architecture. All such aspects are concentrated into the abstraction of Guarantor that CASCOM platform provides because Guarantors are capable of anonymizing interactions. If interactions are anonymous, i.e., only Guarantors know both interacting parties, then privacy problems are inherently solved. The risky situation that IP2P networks tend to realize with respect to security and privacy is exacerbated by the current trend of agent technology in the direction of realizing complex societies of agents. Unfortunately, this evolution of the technology is not yet matched by an equivalent legal development. The lack of a legal substrate capable of grounding the interactions between agents ultimately means that every aspect of interactions with other (possibly unknown) third-parties must be explicitly treated by
187
187
the developer. Furthermore, if we cannot guarantee traceability of the operations of individual agents, no law would be sufficient to prevent and punish mendacious agents (whether human or not). Obviously, traceability does not guarantee that agents could not misbehave; anyway, if they do so, other agents would have the possibility of demonstrating the misbehavior. Therefore, CASCOM provides special-purpose agents, known as Guarantors, with the following main duties: 1.
Provide signed identity credentials to agents;
2.
Verify at runtime the validity of identity credentials; and
3.
Anonymize interactions.
The first two requirements make Guarantors full-featured certification authorities for the agent world capable of providing services, e.g., the runtime verification of credentials, which supersede that of ordinary certification authorities. The provision of certificates is done offline and involves a special user capable of verifying requests for certificates. This part of a Guarantor is made on everyday technology and will use certificate requests (e.g., VeriSign) to provide identity certificates to agents. Last requirement, i.e., anonymization is used when an agent does not want to provide details on its identity to a third party during an interaction. Ideally this anonymization service is designed with the following criteria: 1.
Anonymization is needed only when disclosure-sensible data are transmitted;
2.
Anonymization must be transparent from the receiver point of view: only the sender knows that it is sending disclosure-sensible data through the protection of a Guarantor.
The first requirement is easy to achieve and it is one of the cornerstone of the design of the support for security and privacy-awareness of CASCOM: data can be classified and different policies are applied to different classes of data. On the contrary, the second requirement is somehow tricky. Ideally, there are two ways of performing anonymous interactions through the mediation of a Guarantor. The first, and most trivial, is using Guarantors as proxies for requests and replies. In this way, the contacted third party assumes it is interacting with the Guarantors and has no knowledge of the presence of the original sender behind the scene. This approach to anonymous interactions is perfectly functional and it can be applied always. Anyway, it has the disadvantage from the point of view of the final receiver of masking the identity of the original sender completely. If the receiver is a service provider, it will always provide services to Guarantors and it will never know any detail on the real client. This may be too restrictive for many service providers and therefore another possible scheme of anonymization must be supported. The indirect invocation
188
188
scheme designed in the above in this document has exactly this objective: it provides a way for performing services without spreading sensible data if not explicitly needed by the service provider. The problem of this approach is that it is not transparent from the point of view of the service provider, i.e., it has to agree on using a mediated interaction. CASCOM provides transparent support for indirect interactions through an extensible set of Guarantors that are potentially chained into a mutual recognition hierarchy. Mutual recognition between Guarantors in CASCOM is transparent to interacting parties: shared ontologies could be masked by mapping services of each Guarantor. This means that each agent could know only policy rules stated with respect to its Guarantor’s ontology. On the contrary, if the two Guarantors certified translations to and from a shared ontology, it would be possible to sign the contract in multi-ontology (and possibly multilingual) format. Thanks to mutual recognition, the double-Guarantor model could be simplified to a single-Guarantor model in which a single Guarantor signs the shared ontology. In order to achieve security and trust in multi-Guarantor agreements, there must be a set of ontologies shared by all involved Guarantors. In this case each Guarantor can translate properly the agreement from the shared ontologies to its native ones. The multiGuarantor model is reduced to the single-Guarantor model only if there is a collective recognition.
6 Conclusions and Related Work It is obvious that the subsystems of the CASCOM generic architecture described in preceding Sections need to perform in a well defined manner. Except for the security subsystem which is associated to all other subsystems, they are implemented as autonomous agents and define formal ontologies for message exchange between them. Healthcare applications can make use of the architecture essentially through interacting with them. Regarding the technical approaches used in CASCOM, similar architectures have been developed in the past. Agents2Go [RKJ01] is an agent-based architecture which uses location as a context information in order to provide services to mobile users. The Agents2go architecture is based on (centralized) server, whereas we employ a distributed P2P paradigm. Further, it does not support service coordination (i.e., discovery, composition planning, execution of composite services, execution monitoring, and failure recovery), but only discovery and execution. The Ronin and DReggie system [CPAJ02] is an agent discovery architecture which builds on Jini and provides semantic service matching functionality. Context-information is not taken into account in this architecture, and as in Agent2go, the architecture does not support service coordination. Regarding the work done involving e-health technologies advancement, similar projects can be mentioned. Artemis [D05] project’s focus is on finding and retrieving clinical information about a particular patient from different healthcare organizations where concrete sources are unknown, by providing the interoperability of medical information systems through semantically enriched Web services. PICNIC [RBC02] was an open
189
189
source project to pilot a new generation architecture for regional health care networks to support new ways of providing health and social care. This project’s focus is on the development of a system architecture, common components and tools to support interoperability between (patient-centred delivery of care) services. Healthmate project [H00] aims at providing portable personal systems for health tele-care and teleconsultation based on wireless technologies to configure a secure information exchange media between the personal systems and the health service providers.
References [CPAJ02]
Chakraborty, D.; Perich, F.; Avancha, S.; and Joshi, A.: An agent discovery architecture using ronin and dreggie. In First GSFC/JPL Workshop on Radical Agent Concepts (WRAC), NASA Goddard Space Flight Center, MD, Jan. 2002. [DAS01] Dey, A. K.; Abowd, G.; Salber, D.: A Conceptual Framework and a Toolkit for Supporting the Rapid Prototyping of Context-Aware Applications. Human-Computer Interaction, 2001. [D05] Dogac, A.; Laleci, G.; Kirbas S.; Kabak Y.; Sinir S.; Yildiz A.; Gurcan Y.: Artemis: Deploying Semantically Enriched Web Services in the Healthcare Domain, Information Systems Journal (Elsevier), accepted for publication, 2005. [H00] HealthMate: Personal Intelligent Health Mobile Systems for Tele-care and Tele-consultation. http://www.healthmate-project.org, 2000. [H05] Helin, H.; Klusch, M.; Lopes, A.; Fernandez, A.; Schumacher, M.; Schuldt, H.; Bergenti, F.; and Kinnunen, A.: Context-aware Business Application Service Coordination in Mobile Computing Environments. Proceedings of the AAMAS Workshop on Ambient intelligence – Agents for Ubiquitous Environments, Utrecht, The Netherlands, 2005. [HL01] Hong, J.; Landay, A.: An Infrastructure Approach to Context-Aware Computing. Human-Computer Interaction, 2001. [HPSS06] Helin, H.; van Pelt, T.; Schumacher, M.; Syreeni, A.: Efficient Networking for Pervasive eHealth Applications. Submitted to the workshop on Pervasive EHealth of the First European Conference on EHealth, Fribourg, Switzerland, 2006. [KGS05] Klusch, M.; Gerber, A.; Schmidt, M. (2005). Semantic Web Service Composition Planning with OWLS-Xplan.1st Intl. AAAI Fall Symposium on Agents and the Semantic Web, Arlington VA, USA [RBC02] Rasmussen, M. B.; Bernstein, K.; Chronaki, C.: Collaboration – a new IT-Service in the next generation of regional health care networks. Paper for International Journal for Medical Informatics, 2002. [RKJ01] Ratsimor, O.; Korolev, V.; and Joshi, T. F. A.: Agents2Go: An infrastructure for location-dependent service discovery in the mobile electronic commerce environment. In Proceedings of the First International Workshop on Mobile Commerce, pages 3137, July 2001. [S03] Sadeh, N. M; Chan, T. C.; Van, L.; Kwon, O.; and Takizawa. K.: Creating an open agent environment for context-aware m-commerce. In B. Burg, J. Dale, T. Finin, H. Nakashima, L. Padgham, C. Sierra, and S. Willmott, editors, Agentcities: Challenges in Open Agent Environments, pages 152-158. 2003. [SecPedia] See http://www.infosecpedia.org/pedia/index.php/Main_Page [SSTWS05] Schuler, C., Schuldt, H., Türker, C., Weber, R., Schek, H.-J.: Peer-to-Peer Execution of (Transactional) Processes. In: International Journal of Cooperative Information Systems (IJCIS), 14(4), pages 377-405, 2005.
190
190
