Draft of paper that appeared in the proceedings of the IEEE International Conference on Web Services, 2007
A Platform for Context Aware Runtime Web Service Discovery George Spanoudakis Department of Computing City University London, EC1V 0HB, UK
[email protected]
Khaled Mahbub Department of Computing City University London, EC1V 0HB, UK
[email protected]
Abstract In this paper we describe a platform that supports context aware runtime service discovery. The platform supports service discovery based on structural and behavioural service models as well as complex context related service discovery conditions which are specified in a newly introduced query language. During discovery, context information is obtained through a uniform scheme of calling “context operations” and is subsequently used in the evaluation of service discovery queries.
1. Introduction The importance of context in runtime service discovery has been increasingly recognised and several approaches have been developed to support context awareness in this form of discovery [5][7][14][20][21]. The definition of “context” in these approaches varies. Generally, the term “context” signifies information about the operational environment of a system that may change dynamically (e.g. server workloads, active network connections, availability of resources on networks) or information about the physical environment of the user of a system including, for instance, information about the location of the user, the temperature and lighting conditions around this location and other actors who may exist in user’s environment [1]. Most of the existing research on context-aware service discovery tends to focus on mobile systems and is primarily concerned with the discovery of generic services that are available in the area surrounding the current location of the device used by a user (e.g. printing services or network services). Context information needs also to be taken into account in the discovery of web services that are deployed as part of service based systems (SBSs). Web services, however, are different from the types services which typically constitute the focus of existing context aware service discovery approaches (e.g. printing and networking services). The main difference is that webservices provide forms of functionality which normally cannot be used as standalone computations but need to be assembled and deployed in compositions orchestrated by some coordinating component (e.g. a workflow). An
Andrea Zisman Department of Computing City University London, EC1V 0HBUK
[email protected]
electronic payment web service, for instance, is not useful outside a system that supports purchasing transactions. Effective web service discovery in the case of an SBS often requires the capability to express and evaluate complex conditions about the context of the system itself and/or the services that it deploys. This capability needs also to be integrated with support for evaluating conditions regarding the structure of the inputs and outputs of candidate services and their behaviour in order to ensure that they fit with the system within which they are to be deployed. Consider, for instance, a simple service based system that is running on a mobile phone and enables the user to call a service reporting the currency exchanges which exist within a certain distance from the current location of the phone and provide the best exchange rates for a given currency (this service will be referred to as “ExRS” in the following). In this scenario, the need to discover a new service to replace ExRS arises when this service gives no results either because it is temporarily unavailable or because the current location of the user is not covered by it. In such cases, any candidate service that could substitute ExRS should have input and output data types which are compatible with the types of the data provided and expected by the system. Furthermore, candidate services should have behavioural models that match with the behaviour expected by the SBS. If the SBS in our example expects, for example, ExRS to send an SMS message to it providing the address of a given currency exchange that has been selected by the user, any candidate service for ExRS should be able to provide this behaviour too. Existing approaches to context aware service discovery fail to provide this form of integrated support that is required for service based systems. Typically, these approaches concentrate on context conditions only without supporting other discovery criteria, most notably behavioural criteria. Furthermore, they tend to support the specification of only simple context related conditions. To support context aware runtime service discovery, we have extended a runtime service discovery platform (referred to as “RSD platform” in the following), which has been originally described in [19], with support for the specification and execution of context-based service discovery queries. This platform: (a) provides integrated support for the evaluation of structural, behavioural and
context conditions in runtime service discovery, (b) supports the discovery of services which are described in widely adopted industrial standards such as BPEL [3] and WSDL [23], (c) it assumes a generic mechanism for the description and acquisition of context information based on context services, and (d) provides a query language that enables the specification of complex conditions in discovery queries. The extended platform is described in this paper. The rest of this paper is structured as follows. In Section 2, we give an overview of the discovery platform and the main forms of queries that it supports. In Section 3, we provide an overview of our approach to context based service discovery. In Section 4, we discuss the generic schema for specifying the context types. In Section 5, we introduce the extension of the query language of the RSD platform that enables the specification of context conditions. In Section 6 we give an example of a context based query. In Section 7, we overview related work and finally in Section 8 we give some concluding remarks for our approach.
2. Overview of the RSD Platform The RSD platform is structured as shown in Figure 1 including five main subsystems, namely the REGISTRY, BPEL2SM, WDSL2GRAPH, TYPEMATCHER, CONTEXT EVALUATOR, and SERVICE subsystem.
Figure 1. Architecture of the RSD tool The REGISTRY subsystem provides access to different types of service registries. In the current state of its development, the RSD platform supports service registries with a faceted structure developed in the SECSE project [17] (SECSE is an EU project on service centric systems engineering). In these registries, a web service is
described by a set of facets which represent different viewpoints. The RSD platform uses three different types of such facets, namely a structural service facet describing the operations of a service and their data types using WSDL, a operational semantics facet specifying the behavioural model of a service using BPEL, and a context facet describing the types of context information which are available for a service at runtime and the sources through which this information can be obtained. The WSDL2GRAPH subsystem converts the WSDL specification of a service into a set of type graphs representing the structures of the data types of the input and output parameters of the service operations. These type graphs provide a canonical representation that is used to match the signatures of service operations in registries with the signatures of required operations in RSD queries. The BPEL2SM subsystem converts the BPEL specification of services in RSD queries and service registries into semantically equivalent state machines. These state machines are used to check whether the behaviour of these services match with each other. The TYPEMATCHER subsystem matches the data types of operations in RSD queries with the data types of operations of services in service registries. It also matches the state machines that represent the behaviour of required services in RSD queries with the state machines that represent the behaviour of services in service registries. Both these types of matching are discussed below. The CONTEXT EVALUATOR subsystem parses the context part of RSD queries and evaluates it against the context specifications of services in service registries. Based on this evaluation, this component returns the specifications of services which are compliant with the context conditions of an RSD query. Finally, the SERVICE subsystem coordinates the other components of the RSD platform and exposes its functionality as a web service. At runtime, the RSD platform receives RSD queries consisting of: (i) the BPEL specification of the workflow within which a required service is to be deployed and an identification of the required service in the workflow, (ii) the WSDL description of the required service, and (iii) a specification of the context conditions that the required service should satisfy. The platform extracts from the BPEL workflow the execution paths that make and receive operation calls from the required service and translate them into a state machine. It also translates the WSDL specification of the required service into an operation type graphs and contacts the service registry to find services that can match these descriptions. The matching process has three stages. In the first stage only services which have operations that structurally match the operations of the required service in the RSD query are maintained. Formally, a service operation SO that has an input type graph ITGSO and an output type graph OTGSO matches with a query operation QO that has
an input type graph ITGQO and an output type graph OTGQO if ITGSO is a sub-graph of ITGQO and OTGQO is a sub-graph of OTGSO or, equivalently, if the data types of the input (output) parameters of a candidate service operation are super types (subtypes) of the input (output) parameters of the query operation. The structural matching of service operation data types is based on a variant of the VF2 subgraph isomorphism detection algorithm [8] that we have developed. In the second stage, a service S is maintained in the list of candidate services if each path of the state machine SMQ that has been generated from the query workflow is admissible to the state machine SMS that has been generated from S. A path p of SMQ is admissible into SMS if it can be transformed into some path q of SMS. This transformation is generated by traversing one by one all the transitions in p and checking if each transition ti of p can be: (i) mapped onto the next transition tj in q − ti can be mapped onto tj if it is triggered by the dispatch of an invocation of an operation ox in the required service (i.e. a RS.send(ox) event) and tj is a transition triggered by the receipt of an ox invocation (i.e. a receive(ox) event) or ti is a transition triggered by the invocation of an operation ox in the workflow by the required service (i.e., a RS.receive(ox) event) and tj is a transition triggered by an event W.send(ox), or both ti and tj are transitions that happen automatically (also known as “tau” transitions); (ii) ignored − ti is ignored if it is an internal transition, i.e. a transition triggered by an internal condition check, an assignment of a value to an internal variable of the workflow, an invocation of an operation in a third party service, a receipt of the results of an operation invoked in a third party service, an invocation of an operation by a third party service, or a reply to an operation invoked by a third party service; or (iii) mapped onto the final transition tn of a sub-path of transitions t1,…,tn (n≥1) in q where t1,…,tn-1 are internal transitions of q that can be ignored subject to the conditions of (ii) above. Finally, in the third stage, the context conditions of the RSD query are evaluated and only candidate services which satisfy these conditions are returned to the user. The evaluation of context conditions after the structural and behavioural matching maximizes the chances that the context information which has been used in the evaluation of a query will be valid when the query results are returned back to the user. The specification and evaluation of context conditions is discussed in detail in the following. Further details about the structural and behavioural matching of the RSD
platform, however, are beyond the scope of this paper and can be found in [15][16][19].
3. Overview of Our Approach In the RSD platform, as context we define any type of information regarding an SBS that can change dynamically. This definition covers types of information which have been traditionally perceived as context such as the time and location of the execution of the SBS and the services interacting with it, information about the physical environment of the SBS and its services (e.g. temperature conditions), and information about the operational environment of the SBS and its services (e.g. other processes which might be running on the platform where the workflow or the individual services are running). However, our definition covers also other types of information which have not been perceived as context traditionally but may change dynamically such as the service level agreement under which services may be offered if these agreements, or specific terms in them, change dynamically. Thus, for example, context information could be related to the guaranteed level of service performance and the cost at which a service is available under an agreement, if these two types of information vary between different time periods depending, for instance, on service demand. To provide a uniform mechanism for accessing context information, the RSD platform assumes that such information is provided by a special type of service operations, called “context operations”. A service operation may have more than one context operations. A service operation O1 that gives real time stock information, for example, may have a context operation that gives its average response time over the last X time units and another context service operation that gives the current workload of the execution platform where O1 is running. A context operation may also be related to more than one normal service operations. There might, for instance, be a context operation CO1 that gives information about the number of processes which are executed at a given instance of time on the execution platform of the workflow. As this information is the same for all the operations of the SBS, CO1 can be associated with each of these operations to provide the relevant information for any of them if required. Furthermore, context operations in our approach are grouped into web services and become available through remote invocation. This model enables a uniform and distributed way of disseminating context information that can support effectively several different types of contextual information, e.g. context information available from sensors that have context operations running as their front end, system execution platforms, etc. To enable the location and assessment of the adequacy of context operations for the evaluation of RSD queries, we assume that these operations: (i) are described in
WSDL like normal service operations, and (ii) have a semantic description that is expressed in some ontology. The RSD platform does not impose any restriction regarding the form of the ontology that is used to describe the semantics of context operations. It does, however, assume that ontologies used for this purpose must be referenced according to the schema imposed by the context facet and specified in XML. In the following sections, we present the schema that we use to describe context operations and the query language that is used by the RSD platform to express context conditions.
4. Context Facet A main assumption of our approach is that context information about services and their operations is obtained through special purpose context operations. To specify the context operations which are available for a service, we have introduced a new facet in the service registry that is called context facet. This facet is specified by an XML schema, a graphical view of which is shown in Figure 2 (see [16] for a complete definition).
after it is obtained the information that is returned by the operation will remain valid (time validity), and (iv) a specification of the semantic category of the operation (contextOperationCategory). The identifier of the service that provides the context operation enables initially the location of the WSDL description of this service in the service registry and, subsequently, the invocation of the context operation in this service in order to obtain a context value, dynamically. The semantic categories of context operations are described by ontologies. The element contextOperationCategory includes: (i) a reference to the URI of the XML document that specifies the ontology used to define the context category of an operation (see the element ontology in Figure 2), and (ii) an XPath expression that points to an element in this ontology that defines the particular category (see the element categoryExpression). During the execution of a query, the RSD tool retrieves the description of the context category from the referenced ontology and evaluates if the context conditions in the query are satisfied by it. If they are, the RSD platform calls the relevant context operation to retrieve the required context value for the candidate service operation. Following the invocation, the platform checks if the returned context value is compatible with the type of the context operand that the returned value should be checked against within the query (see Section 5). It should be noted that the structure of the context facet is generic enough to allow the use of different ontologies for context specification and, thus, the RSD platform can be applied in cases where different ontologies are adopted for describing context operations.
5. Specification of Context RSD Queries To specify context conditions in RSD queries we have introduced a new query language, called CA-SQL (Context Aware Service Query Language). CA-SQL is defined by an XML schema fully described in [16]. In the rest of this section, we present an overview of CA-SQL.
Figure 2. The context facet According to this schema, a context facet is associated with a service (see the attribute service in Figure 2), and specifies the different context operations that are available for it, i.e., the elements serviceOperationContexts. The specification of a context operation includes the name of the normal service operation that this operation is associated with (see the element serviceOperation), and a description of it. This description includes: (i) the name of the context operation (contextOperationName), (ii) the identifier of the service that offers this operation (contextServiceId), (iii) a value indicating for how long
Figure 3. Context queries Figure 3 shows a graphical view of the top level of the CA-SQL schema in which a contextQuery is defined as a logical expression or a combination of logical expressions using the logical operators AND and OR. These expressions define atomic conditions over the context aspects of service operations or combinations of atomic conditions. An atomic context condition is defined by a relational operation (e.g. equalTo, notEqualTo, greaterThan, lessThan) over the values of two operands (operand1 and operand2). These operands can be context operands, arithmetic expressions, or constants as shown in Figure 4. The context operands in a query specify the operations that will provide context information at runtime. Since these operations may have different signatures across different services, our approach in CASQL is to specify the semantic category of context operations rather than their actual signature within context operands.
Figure 4. Atomic context conditions More specifically, a context operand is defined by declaring: (i) the name of the service operation associated
with the required context operation, and (ii) the context category of the required operation. The context category of an operation is defined by a logical expression of conditions regarding the description of the category. These conditions are defined by relations over qualified XPath expressions and/or constant values (see Figure 5). A qualified XPath expression includes a reference to an XML document and an XPath that is to be evaluated against this document. The document in a qualified XPath expression may be the context facet of a service in the service registry or the ontology that this context facet uses in order to describe the category of context service operations. Depending on which of these two cases it refers to, a qualified XPath includes either an element called contextFacet that specifies the name of the top level element in the schema of the context facet that is used in the service registry or an element called ontology that specifies the URI where the ontology that is used to describe context operation categories can be found. When the context conditions of a query are evaluated, the RSD platform checks (through the context facet of each candidate service) if a candidate service has a context operation whose semantic category satisfies the conditions of the operation category specified in the query. If it has, RSD calls the operation to obtain the context information that is necessary for the evaluation of the query. CA-SQL can accommodate different ontologies for describing context and context retrieval operations in service registries since it makes no assumptions regarding the structure and meaning of the ontologies used to specify the semantic categories of service operations in context queries. The only assumption is that these ontologies are expressed in XML.
Figure 5. Context categories In addition to context operands, the relational expressions that specify context conditions may take as arguments arithmetic expressions. An arithmetic expression is used to express a computation over the context information and is defined as a sequence of arithmetic operands connected by arithmetic operators as (see Figure 6). The operands of an arithmetic expression can be context operands, constants, or functions. Functions in arithmetic expressions are used to specify the execution of complex computations over a series of arguments. A function operand is defined as an instance of functionType (see Figure 7) and has a name that indicates the function to be performed and a sequence of one or more arguments, which may be context operands, constants or arithmetic expressions themselves. Furthermore, a function can be internal (i.e., a function implemented by the RSD platform) or external (i.e., a function that is performed by an entity external to the RSD platform, for example a web-service).
against the remaining conditions of the query (i.e., the behavioural and structural conditions) and, if they satisfy them, they will be returned as candidate services along with an indication that context conditions have not been checked for them. The optionality of a context query is indicated by the value of the attribute optional of context queries (see Figure 3).
6. Example of RSD queries In the following we give an example of a query that incorporates behavioural and context service discovery conditions and aims to discover an alternative for the ExRS service that we discussed in Section 0. The SBS workflow from which the behavioural part of this query is extracted is shown as a state machine in the left part of Figure 8. From this model, the RSD platform extracts the state machine that specifies the behaviour required for the substitute services of ExRS. As discussed in Section 2, this model is extracted by excluding all the transitions and states of the behavioural model of the system which are irrelevant to the behaviour of ExRS. Thus, the state machine of ExRS that will be part of the query in our example, includes only the grey states and solid transitions shown in the system model of Figure 8 and excludes the transition UIS.receive(selectEx(exc)).
ExRS.send( getExch(c1,c2,n,l))
Figure 6. Arithmetic expressions
ExRS.receive( getExch(elist))
P.receive( getExch(c1,c2,n,l)
P.receive( getExch(c1,c2,l))
P.send( getExch(elist))
P.send( getExch(elist))
UIS.receive( selectEx(exc))
ExRS.send( getPosBySMS(exc))
ExRS.receive( getPosBySMS(add))
Figure 7. Functions It should be noted that a context query in CA-SQL may be optional or compulsory. This distinction is necessary as candidate services might not have context operations or have operations not described by the same semantic categories as those used in RSD queries. In such cases, if the context query is compulsory the services which do not have the required context operations will be ignored. In optional context queries, however, services which do not have the required context operations will be checked
State Machine of S2 P.receive( getPosBySMS(exc))
P.send( getPosBySMS(add))
State machine of State Machine System workflow/ExRS of S1
transition mapping
Figure 8. State machines of ExRS and candidate services As indicated by this model, candidate services for ExRS should provide an operation getExch that identifies n currency exchanges in a location l that offer the best possible exchange rates between currencies c1 and c2, and an operation getPosBySMS that takes as input a currency exchange (exc) and sends an SMS message with the exact
address of this exchange (add) back to the system. Given the state machines of services S1 and S2 in Figure 9, only S1 could be a candidate service for ExRS since its state machine can admit the behavioural model of ExRS according to the matching criteria that we discussed in Section 2 (see the mapped transitions of the two state machines in the figure). S2, on the other hand, cannot replace ExRS since it cannot receive calls of the operation getPosBySMS and respond to these calls. Furthermore, the operation getExch of S2 does not have the same signature as the operation getExch of ExRS. In our example, the query also specifies a context condition for operation getExch. The specification of this condition in CA-SQL is shown in Figure 9. This condition requires that any service offering a candidate operation for getExch should have a location that covers a location of the workflow of the system. To specify this condition, the query uses an internal function called WithinArea. This function takes two locations and a distance measure as arguments and checks if the second location is within the indicated distance from the first location. In the query, the first of these locations is the location that is returned by a context operation of a candidate operation for getExch, and the second location is a location returned by a context operation of the SBS workflow (recall from Section 1 that this workflow runs on a mobile device). www.city.ac.uk/CoDAMoS_Ext.xml string(/owl:Class/@rdf:ID) Location www.city.ac.uk/CoDAMoS_Ext.xml string(/owl:Class/@rdf:ID) Location
10 True
