offered by the other components in the framework. It (a) instantiates service queries to be executed by the matchmaker based on the various situations described ...
Proccedings of IEEE 2008 International Service Computing Conference (SCC ’08)
Proactive Runtime Service Discovery Andrea Zisman, James Dooley, George Spanoudakis Department of Computing, City University, Northampton Square, London, UK. EC1V 0HB. {a.zisman, james.dooley.1, gespan}@soi.city.ac.uk Abstract In this paper we describe a framework that supports runtime service discovery in both pull and push modes. Our framework supports service discovery based on structural and behavioural models of services and applications, as well as quality and contextual constraints. In the approach, we use a proactive push mechanism in which services are identified in parallel to the execution of the system based on subscriptions of services and queries. A prototype tool has been implemented in order to illustrate and evaluate the framework.
1. Introduction The identification of services that can be deployed as part of service-based systems, provided that they can fulfill specific functional and quality properties, has been recognised as an important activity in the development and operation of such systems. Over the last few years, several approaches have been proposed to support service discovery [3][5][13][16][17][21][27][28][34]. These approaches allow services to be discovered in both static and dynamic ways. In static service discovery, services are identified during the development of service-based systems in order to find services that can be used in a loose coupling way in the system. In dynamic (aka runtime) service discovery, services are identified and bound to service-based systems at runtime in order to replace existing services in these systems. The need for runtime service discovery arises when it is necessary to replace a service that becomes unavailable (case A), starts malfunctioning (case B), or can no longer be used due to changes in its context, quality, structure, or behaviour (case C), or due to changes in the context of the system that deploys this service (case D). Runtime service discovery may also be used to identify new services that become available and can fulfill the required quality, contextual, structural, and behavioural properties of a system in a better way than existing services (case E). In the above cases, “context” signifies information about the operational environment of a system or of a service that may change dynamically (e.g., location, server workloads, active network connections, availability of network resources).
To appreciate how the above cases might arise, consider a service-based application that allows users to listen to music in a (mobile) MP3 player. This application enables the user to indicate the characteristics of the music services that he would prefer (e.g. cost of services, level of interruptions in audio streams, speed of audio stream), and tries to locate and connect to services that satisfy these criteria. Suppose a user of this application is listening to a service music programme whilst at his University campus. After 10 minutes of listening to music from this service, however, the service stops broadcasting (case A) and the application searches for a new service and connects to this service. Listening is smooth for a while but as more users connect to the same service (because it is free), the speed of the audio stream from the service drops and music gets interrupted. Thus, the application tries to look for a new service (case C) and finds one that is pay-per-use. As the charge is within the acceptable range for the user, the connection is established and the user is notified. Some time later, when the user moves from the campus to a local café that has a lower network speed than the network speed at the University campus, the recommendable network speed of the connected service is no longer satisfied and an alternative service with a lower recommended speed needs to be found (case D). A service with an appropriate speed range and acceptable pay charge is located and the application connects to this service. Later in the day, a new service that offers the required level of performance and quality at no charge becomes available (case E). The application notifies the user about this service. The scenario above would require the application to execute run-time service discovery for all cases A, B, C, D, and E in order to try to locate new services. For cases A and B, services could be located using classic pull mode of query execution. For cases C, D, and E, however, the pull mode of query execution would not be sufficient since the application would need to poll service registries regularly in order to identify changes in the context of the deployed services (case C) or the existence of new services (case E), and poll the application environment regularly in order to identify changes in its context (case D). Polling mechanisms, however, would require complex programming on the application’s side and would consume significant computational resources as they would need to be executed at regular intervals even if there is no need to do so (i.e., the absence of
service context changes, application environment context changes, or emergence of new services). In order to support the above challenges and avoid the drawbacks of traditional polling mechanisms, in this paper we present a pull and push runtime service discovery framework (called P2RSD in the following) that supports a proactive runtime service discovery mechanism. In this approach, service discovery takes place in parallel to the execution of the system proactively, based on subscriptions of service discovery requests, and pushes the discovered services that fit with the requests to this system once they are located. More specifically, our approach supports a proactive pull runtime service discovery for situations in which there are changes in the structural, behavioural, quality, or contextual characteristics of services; changes in the context of the application environment; or new “better” services become available. P2RSD also supports traditional pull mode of runtime service discovery for cases A and B above. The remainder of this paper is structured as follows. In Section 2 we present an overview of the architecture of our push and pull runtime service discovery (P2RSD) framework with its main components. In Section 3 we describe different scenarios for the P2RSD processes and illustrate our work through some examples. In Section 4 we discuss some implementation aspects. In Section 5 we describe some related work. Finally, in Section 6, we summarise our work and discuss future work
well as information about changes of the context of the services, (f) receives information from the application context server about context of the application environment as well as information about changes of the context of the application environment, and (g) receives information from the service listener about services that become available or changes to existing services. In the framework, a service query may contain five different types of constraints, namely: (a) hard constraints specifying quality of service or other service properties that should be satisfied by all the discovered services, (b) a structural service model, that specifies the interface of a candidate service, (c) a behavioural service model, that specifies the behaviour that the application needs to be fulfilled by a candidate service, (d) soft quality constraints, that specify desired service properties that should be preferably but not necessarily satisfied by the discovered services and can be used to rank the services that satisfy the other compulsory parts of the query (e.g., cost, performance), and (e) context constraints, that specify properties about the operational environment of an application, its users or the services that it deploys. The context constraints may change dynamically during the operation of the service-based system and/or the services that the system deploys (e.g., system location, network availability).
2. Pull and Push Runtime Service Discovery Framework Architecture Figure 1 shows the overall architecture of the P2RSD framework. As shown in the figure, the framework is composed of seven subsystems, namely (a) web service interface, (b) service requester, (c) matchmaker, (d) service registry intermediary, (e) service context server, (f) application context server, and (g) service listener. In addition, the framework uses external service registries and it is invoked by an external client application. We describe below the main subsystems in the framework. The web-service interface provides access to the framework. It represents the entry point of requests and exit point of responses. The service requester orchestrates the functionality offered by the other components in the framework. It (a) instantiates service queries to be executed by the matchmaker based on the various situations described in Section 1, (b) receives responses from the matchmaker, (c) organises the results of a query and returns these results to the web-service interface, (d) manages push mode subscriptions, (e) receives information from the service context server about context of the services as
Figure 1: Architecture of the runtime service discovery framework The hard and soft quality constraints are specified in an XML-based language that we have developed [25], the behavioural service model is specified in BPEL [3], the structural service model is specified in WSDL [32], and the context constraints are specified in an XML-based language that we have also developed [24][29].
The matchmaker is responsible to parse the constraints of a query and evaluate these constraints against service specifications in the various service registries. The evaluation of a query is based on the computation of overall distances between queries and services and is executed in a two-stage process. In the first stage, the query is matched against the services in the registries to check if there are services that satisfy the hard and soft quality constraints of the query, and the structural and behavioural models of the required service. The result of the first-stage process is a set of candidate services that match the above constraints together with the context specifications of these services. The context specifications of these services are evaluated by the service context server subsystem resulting in the context information of these services. In the second stage, the context information of the services returned from the first stage process are matched against the context constraints in the query, resulting in a new set of candidate services that match all the constraints in a query. The first stage matching process is executed in a three sub-stage matching process. The first sub-stage is a filtering stage in which services that match the hard constraints of a query are identified. These services form a set of candidate services. The second sub-stage identifies services that match structural and behavioral models in a query from the set of services returned from the first sub-stage, and generates a new set of candidate services. The third sub-stage identifies services that match the soft quality constraints in a query from the set of candidate services returned from the second sub-stage. The results of the first-stage matching process are services that match all the structural, behavioural, and quality (soft and hard) constraints in a query. When a query does not contain hard, behavioural, soft quality, or any combinations of the above constraints, the possible candidate services are not matched against these constraints. However, in order for a query to be executed by the framework it needs to contain at least structural constraints. When a query does not have hard constraints, the first sub-stage of the matching process (filtering) is not executed and the other constraints in a query are evaluated against all the services in the external service registries. The structural matching between the operations of a query and a service is based on linguistic distances of the names of the operations and their parameters, and the differences of the data types of the parameters in the operations. The parameters data types are compared by using a variant of the VF2 subgraph isomorphism algorithm [7] that we have developed. The behavioural matching is based on the comparison of state machines representing the behavioural specifications of the application and the services, by verifying if these state machines have similar paths and computing distances that
represent the differences between the respective state machines [28]. The matching of the soft quality and context constraints is based on the comparison of these constraints in a query and service specifications representing quality and context information and the computation of respective distances. Details of the structural and behavioural matching of the framework are beyond the scope of this paper and can be found in [24][25][26]. Details of the context and soft quality constraint matching can be found in [29][26]. The service registry intermediary supports the use of different service registries and the discovery of services stored in different types of registries. Its main objective is to provide an interface, which allows the matchmaker to access services from various registries of different types. This subsystem receives incoming requests from the matchmaker and translates them into a format that can be understood by a specific service registry. Similarly, a response from an external service registry is mapped into a format that is understood by the matchmaker component. The service context server and the application context server subsystems allow context information of the services and application environment, respectively, to be disseminated. Both context servers enable context information to be subscribed. In this case, the context server sends updates to the service requester subsystem whenever changes of context in the services or application environment, respectively, occur. The service context server is also responsible to infer context information of a service based on its context description. The service listener subsystem allows information about a new service that becomes available, or information about changes in the structural, behavioural, or quality characteristics of an existing service in an application, to be disseminated when the above type of information has been subscribed. In this case, the subsystem sends information to the service requester whenever changes in the service occur. The external service registries store and maintain various types of service specifications for a certain service including structural specifications represented in WSDL [32], behavioural specifications represented in BPEL4WS [3], quality specification represented in different XML-based schema, and context specification represented in specific XML-based ontologies.
3. Runtime Service Discovery Processes The P2RSD framework can support two main types of query discovery processes, namely (a) pull mode and (b) proactive push mode. In the following we describe these two modes and give examples to illustrate.
3.1. Runtime pull mode query discovery process The runtime pull mode query discovery process is executed when an application instructs the system to locate replacement services due to service unavailability or malfunctioning. Figure 2 presents a simplified sequence diagram illustrating the pull mode process. As shown in Figures 2, an application issues a query to the web-service interface. This query is passed to the service requester subsystem with the necessary characteristics of the service that needs to be replaced in the application, including the context of the application environment. The number of services to be returned by the process that best match a query is also specified. The service requester sends the query to the matchmaker to execute the first-stage of the matching process (see Section 2). The matchmaker requests the service registry intermediary to retrieve services from the external service registries that match the hard constraints of a query, when they are present, or to retrieve all the services when the hard constraints are not present in a query. The matchmaker executes the query against the services following the first-stage process described in Section 2. The results of the first-stage matching process are sent to the service requester.
matching process are sent to the service requester that organises them in the necessary format required by the web-service interface. These results are kept by the service requester to be used in future push mode query discovery process (see Subsection 3.2). The results are also returned to the web-service interface and passed to the client application. Example. In order to illustrate the pull mode query discovery process, consider the service-based application for mobile MP3 player described in Section 1. Suppose that this application offers, among others, the following functionality: (i) stream of music in MP3 format from a remote service, (ii) decode of this music stream, (iii) render of this music stream as audio to a user. Consider the application is currently using service SA as described in Table 11 to support some of its functionality. Table 1: Summarised examples of service specification Service Operation SA O1: getStream() O2:getCurrent Trackname()
SB
Behaviour Context Quality O1 < O2 Status: running Cost per day: O2 < O3 £1 Location:any Stream format: MP3
O3:registerVote (trackname) O1: O1 < O2 getMusicStream () O2 < O3 O2:getCurrent SongName()
Status: running Cost per day: £1.20 Location: any Stream format: MP3
O3:voteForSong (trackname)
Table 2: Example of query Q1 Constraint Type Hard quality Soft quality Structural and behavioural Contextual
Legend: App-Application, WS-Web-Service Interface, SR-Service Requester, SCS-Service Context Server, MM-Matchmaker
Figure 2: Sequence diagram for pull mode query discovery process After receiving the results of the first-stage process, the service requester invokes the service context server with these results and receives context information of the services. The service requester sends to the matchmaker the context constraints of the query together with the context information of the services to be evaluated (second-stage of the matching process as described in Section 2). The results of the second-stage of the
Constraint Value Stream format = MP3 Cost per day < £1.50 The same as service SA The context of the application environment
Consider query Q1 associated with service SA. Suppose that Q1 has constraints as summarised in Table 2. Figure 3 presents part of the soft quality constraint in Q1 described in our XML-based language [25]. Due to space limitations we do not present the hard quality, structural, behavioural, and contextual constraints of Q1 in the query language. Consider that during the execution of the application service SA becomes unavailable (case A in Section 1). In this case, a service that can replace SA needs to be 1
Due to lack of space we do not present here the full structural and behavioural models of the services and the schema representing the context and quality aspects of the services.
identified. The application issues Q1 to the web-service interface that passes it to the service requester. This subsystem sends the query with all the necessary information to the matchmaker. Suppose that after the first and second stages of the matching process service SB (as shown in Table 1) is identified as a candidate service to Q1, together with other candidate services (not shown here due to space limitation). Service SB matches most of the constraints in Q1 and has a very similar structural model to SA. The results of the process are kept by the service requester and sent to the web-service interface that passes them to the application in order to replace SA with SB. QoS QoS //Metrics//Metric[Name=“cost”] MaxValue 1.5 GBP
Figure 3: Example of soft quality constraints
A push mode service discovery process requires a pull mode process to be executed for the subscribed services and respective queries. This pull mode discovery process can be performed as a response to a service that becomes unavailable or malfunctioning, or as a pre-step for services subscribed for the push mode process. The three cases in which a proactive runtime push mode query discovery process is executed are described below. For each of these cases consider S1 one of the services participating in application APP1, and Q1 a query for S1. Assume that a pull mode service discovery process has been executed for S1 and Q1. Consider Set_S1 the set of candidate services returned by the execution of the pull mode process (services that match the structural, behavioural, quality and contextual constraints of Q1) as described in Subsection 3.1. Note that Set_S1 also includes service S1. In order to support a proactive runtime push mode query execution, consider that APP1, service S1, query Q1, and the candidate services in Set_S1 have been subscribed for push mode process. The subscriptions of services in Set_S1 guarantee that this set of candidate services is maintained up-to-date with respect to query Q1 and application APP1, allowing a more efficient service discovery, and subsequently, replacement of services in the application during runtime execution. In order to allow for an efficient proactive push mode service discovery process, we propose to have a small number of services in Set_S1 (i.e., the number of returned candidate services). This set is constantly been updated and, therefore, if better services that fulfill the query become available, they will be included in the set. Case 1: Changes in the context, quality, structural, or behavioural characteristics of a subscribed service (S1)
3.2. Runtime push mode query discovery process The runtime push mode query discovery process is executed in a proactive way when (i) there are changes in the structural, behavioural, quality, or contextual aspects of a service being used by an application, (ii) there are changes in the context of an application environment, or (ii) a new service becomes available. The runtime push mode process requires subscriptions of service requests. More specifically, an application needs to subscribe its environment and its participating services, with their associated queries, so that services can be replaced in the application when changes of types (i), (ii), or (iii) above occur. The use of subscriptions allows asynchronous events to be pushed to listeners removing the need for executing polling mechanisms. In the framework, the listeners are the application context server, service context server, and service listener subsystems (see Section 2).
In this case, the new version of service S1 needs to be evaluated against query Q1 to see if S1 continues to match Q1. If not, a new service that matches Q1 needs to be identified to replace S1 in the application. This case can be divided into two sub-cases, as described below. Case 1.a: Changes in the context of service (S1) The service context server informs the service requester that a change has occurred in the context aspects of S1 and provides the new context information for S1. The service requester sends query Q1 together with the new context information of S1 to the matchmaker in order to evaluate the context characteristics of Q1 against service S1 (second-stage of the matching process as described in Section 2). In this case, service S1 does not need to be matched against structural, behavioural, or quality constraints in Q1 since
S1 has not been changed with respect to these aspects. The result is sent to the service requester. In the case in which the new context characteristics of S1 match Q1, nothing needs to be done. Otherwise, a service S2 in Set_S1 is used to replace S1 in the application. This set is being constantly updated since its services have been subscribed for changes in their structural, behavioural, quality, and contextual characteristics. The result of the process is passed to the web-service interface subsystem and subsequently to the application client. In the situation in which Set_S1 is empty (i.e., there are no services in the registries that can fulfill the query), the web-service interface informs the application that there are no available services. However, it has to be appreciated that, although possible, this situation is very difficult to happen. Case 1.b: Changes in the quality, structural, or behavioural characteristics of a subscribed service (S1) The service listener informs the service requester that a change has occurred in S1 together with the type of characteristic that has been changed (i.e., structural, behavioural, or quality). The service requester sends query Q1 together with the type of change in S1 to the matchmaker. The matchmaker evaluates the new version of the service specification of S1 against the respective constraint of Q1 by accessing the respective specification from the external service registries through the service registry intermediary (first-stage of the matching process described in Section 2). The result of this matching process is reported to the service requester. In the case in which the new specification of S1 matches Q1, nothing needs to be done. In this case, S1 does not need to be matched against context constraints (second-stage of the matching process) since the context of S1 has not been changed. However, when the new version of S1 does not match Q1, a service S2 in Set_S1 is used to replace S1 in the application. The result of the process is passed to the web-service interface subsystem and subsequently to the application client. Similarly to case 1.a, if Set_S1 is empty (i.e., there are no services in the registries that can fulfill the query), the web-service interface informs the application that there are no available services. Case 2: Changes in the context of the application environment In this case, the context constraint of Q1 is modified. Assume Q1’ the new version of Q1 with the modified context constraint. The application context server informs the service requester that a change has occurred in the context characteristics of the application environment. In
this case service S1 and the other services in Set_S1 need to be evaluated against the new context constraints in Q1’ (second stage of the matching process). The services in Set_S1 already match the other constraints of the query that have not been modified. The service requester subsystem sends Set_S1 and Q1’ to the matchmaker subsystem in order to evaluate the context conditions of Q1’ against Set_S1. For this situation, if a new set of services Set_S3 that is a sub-set of (or equal to) Set_S1 that match the context conditions of Q1’ is identified, this set will replace Set_S1. Moreover, if S1 is in Set_S3, nothing else needs to be done. However, if S1 is not in Set_S3, a service S2 from Set_S3 is used to replace S1 in the application. In the case in which no service in Set_S1 match the context conditions of Q1’, the new version of the query is evaluated against the services in the external registries in order to build a new set of candidate services for Q1’. In this case, a service in this new set is used to replace S1 in the application and all the services in the set are subscribed together with query Q1’ for future push mode service discovery iterations. The result of the process is passed to the web-service interface subsystem and subsequently to the application client. In the situation in which there are no services in the registries that can fulfill Q1’, the web-service interface informs the application that there are no available services. Case 3: A new service becomes available Suppose that a new service S3 becomes available. In this case, the service listener informs the service requester that S3 is available. The service requester sends S3 and Q1 to be evaluated by the matchmaker (first and second stages of the matching process). The matchmaker sends the results of the matching process to service requester. If S3 matches the constraints of Q1, S3 is added to Set_S1 and is subscribed for push mode service discovery. In addition, the service requester compares the results of the matching of Q1 against S3 and against S1 in order to see if the former is better than the latter. If S3 matches Q1 better than S1, S3 could be used to replace S1 in the application. However, the application may be in the middle of its execution and the immediate replacement of S1 with S3 may not be desired. Therefore, the application needs to decide if and when to replace the service. For example, in the music scenario described in Section 1, the user may not want to stop listening to a music programme that is currently being played when a better service is found. We propose to have policies in the application to specify when a better identified service should be substituted in the application.
The framework also guarantees that the subscribed services in Set_S1 are maintained up-to-date with respect to Q1. More specifically, when there are changes in the structural, behavioural, quality, or contextual characteristics of a service in Set_S1, this is reported to the service requester by the service listener or service context server. The service requester invokes the matchmaker to evaluate the changed service against query Q1 (similar to Cases 1.a and 1.b). When the new version of the service does not match Q1, this service is removed from Set_S1. The other cases in which Set_S1 is updated have been described in Cases 2 and 3 above. Example. In order to illustrate the push mode query discovery process, consider the example of service-based application described in Subsection 3.1. Suppose that the application is using service SB to support its functionality after service SA became malfunctioning. Consider that query Q1 together with all the candidate services for SA returned in the example in Subsection 3.1 are subscribed for push mode discovery process. Table 3: Summarised example of service specification Service Operation Behaviour Context Quality SC O1: getStream() O1 < O2 Status: running Cost per day: £0 O2 < O3 O2:getCurrent Location:any Stream format: Trackname() MP3 O3:registerVote (trackname)
Assume that a new service SC as shown in Table 3, becomes available (Case 3 above). In this case, the service listener is notified about this new service from a service registry, and informs the service requester about the availability of SC. The matchmaker compares SC with Q1 and returns the result to service requester. In this case, SC matches Q1 in all its constraints. For both structural and soft quality constraints, SC has a better match than SB (i.e., it has a smaller overall distance value with respect to Q1 than SB). SC is added to the set of candidate services associated with query Q1 and might be used to replace SB in the application.
4. Implementation Aspects The components of the P2RSD framework have been implemented in Java. The framework itself is exposed as a web service allowing it to be deployed by any client that is able to produce service queries in the format required by the framework. In the current implementation, the service registries use an eXist XML database [10]. Future implementation will support other types of persistent storage for service specifications such as UDDI [30]. The
specification of service subscriptions for the push mode process is assisted by ws-eventing [33]. An initial implementation of the matchmaker is available in order to illustrate and evaluate the work. We plan to extend the matchmaker implementation to support optimisation of the execution of the runtime push mode service discovery process. More specifically, we would like to analyse the frequency in which the different aspects of a service change (i.e., structural, behavioural, quality, and contextual aspects) and allow parallel matching of services against queries for those aspects that change more often in order to enhance the productiveness of the discovery process.
5. Related Work Several approaches have been proposed to support service discovery. We present below an account of some of these approaches. Some semantic matchmaking approaches have been proposed to support service discovery based on logic reasoning of terminological concept relations represented as ontologies [1][2][14][17][20][21][31]. In [2], the METEOR-S system adopts a constraint driven service discovery approach in which service requests are integrated into the composition process of a service-based system. The work in [1] considers semantic, temporal, and security constraints for service discovery. In our framework, the service requests contain extra constraints concerned with the structure and behaviour of the application, quality of services, and contextual information of the services and application environment. In [14] the discovery of services is addressed as a problem of matching requests specified as a variant of Description Logic (DL). The work in [20] extends existing approaches by supporting explicit and implicit semantic by using logic based, approximate matching, and IR techniques. The work in [31] proposes QoS-based selection of services. Our work differs from the above approaches since it supports the discovery of services based on the linguistic distances of the operation request and service operations and their input and output parameters, but also on the structure of the data type graphs of these parameters, the behaviour of the applications and services, and the context of the application and services. Hausmann et al. [13] propose the use of graph transformation rules for specifying both requests and services. The matching criteria in our work are more flexible and based on distance measures quantifying similarities between the graphs. The approach in [19] focuses on interface queries where operation signature checking is based on string matching and cannot account for changes in the order or names of the parameters. In
[12] the authors advocate the use of (abstract) behavioural models of service specifications in order to increase the precision of service discovery process. Similarly, in [27], the authors propose to use service behaviour signatures to improve service discovery. The work in [11] also suggests behavioural matching for service discovery based on similarity measures of graphs. This work has been used to compare behavioural models represented in WSCL. Our work considers not only behavioural aspects of services specified in BPEL, but also other service properties. In addition, the above approaches do not consider the discovery of services in a proactive push mode. Several approaches have been proposed to support context awareness in service discovery including [3][5][6][8][9][18][22]. In [9], the authors describe a system for context aware service discovery in which context information is represented by key-value pairs attached to the edges of a graph representing service classifications. This approach does not integrate context information with behavioural matching and, since context information is stored explicitly in the service repository, this repository must be updated following context changes. The context aware service discovery approach of [5] uses ontologies to express service queries, service descriptions, and context information. Context information in this approach can also be used as an implicit input to a service that is not explicitly provided by the user (e.g. user location). The approach in [3] focus on user context information (e.g. location and time) and use it to discover the most appropriate network operator before making phone calls. In this approach, context information is used to calculate charges prior to the service set up time, by taking into account context information about the user. Other approaches focus on service discovery protocols in mobile computing with support for context awareness [6][22]. Overall, most of the approaches support service discovery for a certain type of constraint in pull mode execution process. Unlike these approaches, our framework allows for the runtime discovery of services based on various types of service and application characteristics such as structural, behavioural, quality, and contextual. Moreover, our framework allows for both pull and proactive push service discovery mechanisms maximising the way that services are replaced during the execution of an application.
6. Conclusion and Future Work In this paper we have described a runtime service discovery framework that supports both pull and push discovery processes. Our framework also supports service discovery based on structural and behavioural service models as well as quality and contextual constraints. The runtime push service discovery process supports the identification of services in a proactive way due to (a) changes in the structural, behavioural, quality, or
contextual characteristics of a service, (b) changes in the context of an application environment, and (d) availability of a new service that can support the structural, behavioural, quality, and contextual characteristics of a system in a better way. We are currently performing experimental evaluation of the framework in industrial case studies. Some initial experiments have demonstrated that the approach scale for service registries with a large number of services. We are also investigating how to represent information about the services that need to be subscribed for the push mode process in the application and how to describe the policies in the applications representing when a service should be substituted in the application. Additional on-going work in the framework are concerned with the analysis of the size of candidate services used to assist the push service discovery process, and measure of the frequency of changes in different aspects of the service to assist with the optimisation of the push mode process.
8. Acknowledgement The work presented in this paper has been funded by the European Commission under the Information Society Technologies Programme as part of the project GREDIA (contract FP6-34363).
9. References [1] S. Agarwal and R. Studer. Automatic Matchmaking of Web Services, IEEE International Conference on Web Services, ICWS, USA, September 2006. [2] R. Aggarwal, K. Verma, J. Miller, and W. Milnor. Constraint Driven Web Service Composition in METEORS, International Conference on Service Computing, SCC, China, November 2004. [3] F. Bormann, et al, Towards Context-Aware Service Discovery: A Case Study for a new Advice of Charge Service, 14th IST Mobile and Wireless Communications Summit, June 2005. [4] BPEL4WS. http://www128.ibm.com/developerworks/ library/specification/ws-bpel/ [5] T. Broens, S. Pakraev, M. van Sinderen, J. Koolwaaij, and P.D. Costa. Context-aware, ontology-based, service discovery. Lecture Notes in Computer Science, LNCS 3295, 72-83, 2004. [6] L. Choonhwa and S. Helal. Context Attributes: An Approach to Enable Context-awareness for Service Discovery, 2003 Symp. on App. & the Internet. [7] L.P. Cordella, P. Foggia, C. Sansone, and M. Vento. An Improved Algorithm for Matching Large Graphs, 3rd IAPRTC15 Workshop on Graph-based Representations, Ischia, 2001. [8] S. Cuddy, M. Katchabaw, and H. Lutfiyya. Context-Aware Service Selection Based on Dynamic and Static Service
Attributes. IEEE Int. Conf. on Wireless and Mobile Computing, Networking and Communications, 2005. [9] C. Doulkeridis, N. Loutas, and M. Vazirgiannis. A System Architecture for Context-Aware Service Discovery. Electr. Notes Theor. Comput. Sci. 146(1): 101-116 (2006). [10] eXist. http://exist.sourceforge.net [11] D. Grigori, J.C. Corrales, and M. Bouzeghoub. Behavioral Matchmaking for Service Retrieval, IEEE International Conference on Web Services, ICWS, USA, September 2006. [12] R.J. Hall and A. Zisman. Behavioral Models as Service Descriptions, 2nd International Conference on Service Oriented Computing, ICSOC, New York, 2004. [13] J.H. Hausmann, R. Heckel and M. Lohman. Model-based Discovery of Web Services, IEEE International Conference on Web Services, ICWS, USA, 2004. [14] I. Horrocks, P.F. Patel-Schneider, F. and van Harmelen,. From SHIQ and RDF to OWL: The Making of a Web Ontology Language, Journal of Web Semantics, 1(1), 7-26, 2003. [15] W. Hoschek. The Web Service Discovery Architecture, IEEE/ACM Supercomputing Conf., Baltimore, USA, 2002. [16] S. Jones, A. Kozlenkov, K. Mahbub, N. Maiden, G. Spanoudakis, K. Zachos, X. Zhu, A. Zisman: Service Discovery for Service Centric Systems, eChallenges 2005, Slovenia, October 2005. [17] U. Keller, R. Lara, H. Lausen, A. Polleres, and D. Fensel. Automatic Location of Services, European Semantic Web Conference, 2005. [18] M. Khedr and A. Karmouch. Enhancing Service Discovery with Context Information, Intelligent Tutoring Systems, ITS, Spain, June 2002, Lecture Notes in Computer Science 2363 Springer 2002, ISBN 3-540-43750-9ITS'02, 2002. [19] M. Klein and A. Bernstein. Toward High-Precision Service Retrieval. IEEE Internet Computing, 30-36, January 2004. [20] M. Klusch, B. Fries, and K. Sycara. Automated Semantic Web Service Discovery with OWLS-MX, International Conference on Autonomous Agents and Multiagent Systems (AAMAS), Japan, 2006. [21] L. Li and I. Horrock. A Software Framework for Matchmaking based on Semantic Web Technology, WWW
[22]
[23]
[24] [25] [26] [27]
[28]
[29]
[30] [31]
[32] [33] [34]
Conference Workshop on E-Services and the Semantic Web, 2003. P.Pawar and A. Tokmakoff. Ontology-based Contextaware Service Discovery for Pervasive Environments, IEEE International Workshop on Service Integration in Pervasive Environment, June, 2006 D. Preuveneers, J.V. den Bergh, D. Wagelaar, A. Georges, P. Rigole, T. Clerckx, Y. Berbers, K. Coninx, V. Joncke, and K. De Bosschere. Towards an Extensible Context Ontology for Ambient Intelligence, LNCS 3295, 2004. SECSE A2.D4, Platform for Runtime Service Discovery V1.0: Specification, April 2006 SECSE A2.D9. Platform for Runtime Service Discovery – v2.0, January 2007 SECSE A2.D13. Platform for Runtime Service Discovery” – v3.0, September 2007 Z. Shen and J. Su. Web Service Discovery based on Behavior Signatures. Int. Conf. on Service Computing, SCC, USA, July 2005. G. Spanoudakis, A. Zisman, and A. Kozlenkov. A Service Discovery Framework for Service Centric Systems, IEEE International Conference on Services Computing, SCC, USA, July 2005. G. Spanoudakis, K. Mahbub, and A. Zisman. A Platform for Context-Aware Run-time Service Discovery, IEEE International Conference on Web Services, ICWS, USA, 2007. UDDI. http://uddi.xml.org/ X. Wang, T. Vitvar, M. Kerrigan, and I. Toma. A QoSAware Selection Model for Semantic Web Services, 4th International Conference on Service Oriented Computing, ICSOC, USA, December 2006 WSDL. http://www.w3.org/TR/wsdl WS-Eventing. http://www/w3/org/Submission/WSEventing A. Zisman, K. Mahbub, and G. Spanoudakis. A Service Discovery Framework based on Linear Composition, 2007 IEEE International Conference on Services Computing, SCC, USA, July 2007
