A Service Discovery Framework for Service Centric ... - Semantic Scholar

14 downloads 1033 Views 280KB Size Report
providers and integrators have to identify web-services that can realise .... monitoring requirements of SCS and its services at run- time. The monitoring of ...
Appeared in the proceedings of IEEE Conference in Service Computing 2005

A Service Discovery Framework for Service Centric Systems George Spanoudakis Department of Computing City University London, United Kingdom [email protected]

Andrea Zisman Department of Computing City University London, United Kingdom [email protected]

Alexander Kozlenkov Department of Computing City University London, United Kingdom [email protected]

requirements but also provide the behaviour and any other quality-of-service characteristics of the services (e.g., performance) that violated these requirements without human intervention at run-time, (c) efficient execution of these queries at run-time, and (d) the dynamic substitution of services during system execution. In the last few years, different approaches have been proposed to support service discovery. Some of these approaches support discovery based on keyword matching similar to web search engines such as Google and Yahoo. Other approaches make use of descriptions of service interfaces (WSDL [17]), and can discover services based on matching their names and the operations that they provide, and the input and output parameters of these operations. Extensions of interface-based approaches in which the order of the execution of service operations (typically defined in service choreography languages like WSCI [15]) has also been proposed. Examples of these extensions are the conversation-based approaches (WSCL[16], Benattalah et al [4]). There have also been approaches in which services are described using pre- and post-conditions (OWL-S [6], Baresi et al [3]), behavioural types [12], and full abstract behavioural specifications of the services (OMML [8]). Clearly, the move from the deployment of simple service interface descriptions to the use of behavioural service specifications provides scope for implementing discovery processes that can achieve increased levels of precision. However, to the best of our knowledge, none of the existing architecture discovery approaches [1][9][14] provides an integrated framework having all the capability to support (a)-(d) above. To address this shortcoming, in this paper we propose a framework for run-time service discovery that provides these capabilities. The key contribution of this paper is the combination of components for monitoring the compliance of service-centric systems with requirements at run-time, and components for discovering services at run-time. The former components detect violations of requirements at run-time. The framework uses the specifications of the violated requirements to generate queries for discovering services that could substitute for malfunctioning services. These queries incorporate both structural and behavioural aspects of the required services and are executed by the run-time service discovery components of the framework. Another novel characteristic of the framework that we propose is that it advocates a non-intrusive approach, which ensures that the monitoring of requirements and all

Abstract An important aspect of service-centric systems (i.e. systems composed of services) is the ability to support service discovery at run-time in order to cope with unavailable or malfunctioning services. In this paper we present a framework that supports run-time service discovery. The central characteristic of this framework is the combination of components for monitoring the compliance of service-centric systems with requirements at run-time and components for discovering services at run-time. The framework uses the former components to detect violations of requirements at run-time and uses the specifications of the violated requirements to generate queries for discovering services that could substitute for malfunctioning services. It also uses queries derived from the process specification for service discovery. These queries incorporate both structural and behavioural aspects of the required services.

1. Introduction The construction of software systems as compositions of autonomous services is an emerging approach of software systems development. In this approach, system providers and integrators have to identify web-services that can realise different parts of the functionality of a system and compose them into it through the use of an appropriate system composition process. Systems developed using this service oriented implementation approach will be referred to as service-centric systems (SCS) henceforth. One of the key challenges for the effective realisation of the service-oriented system implementation approach is the ability to support not only static but also dynamic, i.e., run-time, discovery and composition of services into service centric systems. Run-time service discovery is necessary for locating alternative services that could replace services already integrated in a service-centric system that become unavailable or fail to meet specific functional or quality requirements for the system during its execution. Run-time service discovery is a challenging activity as it requires capabilities to support: (a) the identification of existing services that fail to comply with specific functional and non-functional requirements for servicecentric systems, (b) the generation of queries to retrieve alternative services that can not only satisfy the violated

1

Appeared in the proceedings of IEEE Conference in Service Computing 2005

to allow customers to cancel completed rental transactions if they are not happy with the cars that they have rented up to 40 minutes following the completion of a car rental. To support this feature, CRS providers update the UI services deployed by CRS in order to be able to handle the relevant requests. They also check the specification of the PS service that CRS deploys and, as they find that the specification does not always entail the negation of the requirement1, they decide to continue using the service. However, they also start observing the behaviour of PS to check if it always satisfies the requirement during the operation of the system. For a certain period of time, PS behaves in line with the requirement but at some point a violation (i.e., a denial to return a payment) is observed for a car rental cancellation request. In this case, to ensure uninterrupted availability to its customers, CRS should continue using PS while trying to find another payment service to replace it at run-time. The new service should: (a) guarantee the satisfiability of the violated requirement, (b) offer the behaviour of PS that is used by CRS, and (c) satisfy any other quality of service requirements offered by PS. Furthermore, if a new payment service is found, it should be possible to introduce the new payment service to CRS at run-time. Dealing effectively with the above scenarios requires a run-time service discovery framework to be able to: (i) keep an SCS alive when a service deployed by it fails and until a replacement service is found; (ii) monitor the compliance of the run-time behaviour of the SCS’s services with specific requirements; (iii) create queries based on violated requirements to find alternative services that can satisfy these requirements; and (iv) create queries based on the operations and qualityof-service requirements of unavailable services to find services to replace them.

other processes necessary for the discovery and substitution of services are executed in parallel with the execution of the service-centric system without wasting computational resources that could affect its performance. Finally, the proposed framework uses behavioural specifications of services based on state machines that are essential for precise service discovery, as shown in [8]. The remainder of this paper is structured as follows. In Section 2, we describe scenarios for run-time service discovery that we will use throughout the paper to illustrate our work. In Section 3, we describe the architecture of the framework and the main components of it. In Section 4, we give an account of related work. Finally, in Section 5, we summarise our approach and discuss directions for future work.

2. Scenarios for run-time service discovery To illustrate our approach we will use an example of a car rental system (CRS). CRS acts as a broker offering its customers the ability to rent cars provided by different car rental companies, directly from car parks at different locations. CRS is implemented as a service centric system consisting of a composition process interacting with: ƒ Car information services (IS) which are provided by different car rental companies to maintain registries of cars, check car availability, and allocate cars to customers as requested by CRS. ƒ Sensoring services (SS) which are provided by different car parks in order to sense cars as they enter in or depart from car parks, and inform CRS accordingly. ƒ User interaction services (UI) that provide CRS with front-ends to handle interactions with end-users. ƒ A Payment service (PS) that CRS uses to take electronic payments for car rentals. In a typical situation, CRS receives a car rental request from a UI service and checks for the availability of cars by contacting IS services. If an available car can be found at the requested location, CRS books the car rental through an IS service, and takes payment through the PS service. When cars move in and out of car parks, respective SS services inform CRS, which subsequently invokes operations in IS services to update the availability status of the moved car. During the execution of CRS, a composed service used by CRS may become unavailable or fail to meet certain requirements as described in the scenarios below. Scenario 1 (unavailable service): A customer requests CRS to find if there are cars available for renting at a specific car park. After confirming the availability of cars at the specific location and their prices, and checking with the customer whether he/she wants to proceed with the rental, CRS contacts payment service PS to get a payment for the rental. PS, however, is not available. To continue its operation in this scenario, CRS needs to find another payment service to replace PS. A valid candidate service should: (a) provide all the operations that PS provides and are used by CRS, and (b) satisfy any other quality-ofservice requirements that PS meets. Scenario 2 (malfunctioning service): To offer higher flexibility to their customers, the providers of CRS decide

3. Service discovery framework 3.1. Overview Our run-time service discovery framework incorporates four main components: a service-centric system (SCS) manager, a run-time requirements monitor, a run-time discovery tool, and an instrumentor. These components are architecturally structured as shown in Figure 1. The framework assumes that a service-centric system is built as a collection of web-services, which are coordinated by a composition process specified in BPEL4WS [2]. It also assumes that, at run-time, a process execution engine executes the BPEL4WS composition process and delivers the functionality of the system. This process execution engine is referred to as SCS execution environment in Figure 1. The central component of our architecture is the SCS manager. This component has responsibility for: (i) overseeing the monitoring of functional and quality-of1

2

Formally, this is equivalent to proving that ¬ (∀x. S(x) ⇒ ¬ R(x)) where S(x) is the specification of a service x and R(x) is the requirement about x.

Appeared in the proceedings of IEEE Conference in Service Computing 2005

violated, (b) the malfunctioning service(s) that violated it, and (c) diagnostic information regarding the violation. Based on the type of the deviation notification and service monitoring policies, the SCS manager creates and sends service query to the run-time discovery tool. The SCS manager can also send a service query to the service discovery tool if, during the execution of SCS, the SCS execution environment reports to it that a service used by SCS is no longer available. The run-time service discovery tool searches different service registries to locate alternative services. When such services are identified, the runtime service discovery tool reports them back to the SCS manager, which decides whether they can be incorporated into the system.

service requirements regarding SCS, (ii) making decisions on whether to issue requests for discovering candidate services to replace unavailable or malfunctioning services of SCS, (iii) creating service queries for discovering candidate services, and (iv) replacing services in SCS. The run-time requirements monitor is responsible for monitoring requirements of SCS and its services at runtime. The monitoring of requirements is triggered by requests issued by the SCS manager (see SCS monitoring requests in Figure 1). Monitoring requests include an identification of the run-time system to be monitored, and specifications of the requirement(s) to be monitored. The monitor sends deviation notification to the SCS manager when requirements variations are detected. This notification indicates: (a) the requirement that has been

InstrumentedSCS specification

Instrumentor

SCS specification (BPEL4WS)

requirements to be monitored SCS providers

service specifications + QoS deployment data

SCS execution environment

S1 Service ƒ introduction ƒ replacement, and ƒ monitoring policies

Service Registries

unavailable services

Sn

replacement/ new services

SCS manager SCS monitoring requests

Run-time events

Run-time requirements monitor(s)

service queries

service deployment data candidate services

deviation notification

Run-time service discovery tool (s)

Figure 1: Architecture of run-time service discovery framework these services by names expressed in the partnerLink attribute. Normally, these names are assigned specific service endpoints based on information described in configuration files of composition process execution environment.

3.2. Instrumentor In order to allow for a non-intrusive run-time service discovery approach, we use an instrumentor that introduces code fragments into the composition process of a SCS. The code fragments introduced by instrumentation allow the composition process to: (a) report unavailable services to the SCS manager, (b) request the SCS manager for dynamic service substitutions, and (c) substitute services dynamically as suggested by the SCS manager. The instrumentor receives as input the composition process P of SCS together with a service replacement policy (see Figure 1), and generates as output an instrumented process PI. For each type of instrumentation (a)−(c) above, a different code block is introduced in PI. As an example, consider the instrumentation required for issuing a request to SCS manager for service substitution (type b instrumentation). Figure 2 shows an extract of the composition process for the CRS system expressed in BPEL4WS. This extract includes the initialisation of the process (see the first activity in Figure 2) and an invocation of the operation authorise in the PS service. The invocation of operations in BPEL4WS does not explicitly specify the exact services that should receive these invocations, but refer to



Figure 2: Fragment of the CRS composition process The BPEL4WS code that is used to instrument the CRS composition process in order to allow dynamic replacement of a payment service by another service (and not the specific one in the configuration file) is shown in Figure 3. According to the inserted code fragment, the CRS composition process will request the SCS manager of CRS to provide a specific endpoint (location) of the payment service to be substituted (see the activity in the BPEL4WS code in Figure 2).

3

Appeared in the proceedings of IEEE Conference in Service Computing 2005

The inserted code fragment shown in Figure 3 initialises in the first activity a request to the SCS manager by providing the logical name of the requesting process (‘CRS’) and requested service (‘PaymentSystem’). Then, it invokes the operation endpoint of the SCS manager (see first activity in Figure 3) which returns the current service that replaces the default PS endpoint. The SCS manager identifies the current payment service through a local registry of substitutions for endpoints which are used by specific processes (in this case the specific instance of CRS). The returned endpoint (i.e., the value of the variable endpointResponse) is assigned to wsa:Address and then the whole wsa:EndpointReference to the partnerLink of PS (see the final two activities in Figure 3).



Figure 4: Instrumentation for realising service substitution requests from the SCS manager

3.3. Run-time requirements monitor The run-time requirements monitor receives requests for monitoring specific requirements from the SCS manager or individual web services. This component of our framework is implemented according to the approach that is discussed in [11]. The requirements to be monitored may be related to the behaviour or quality properties that should be provided by an individual service of the service-centric system, or groups of such services. These requirements are expressed in event calculus (EC) in terms of events and fluents. An event is something that occurs at a specific instance of time, has instantaneous duration and may change the state of a system (e.g., invocation of an operation, assignment of a value to a variable). In the context of service-centric systems, an event can signify: (i) The invocation of an operation by the composition process of the system in one of its partner services or the return from this execution. (ii) The invocation of an operation in the composition process of the system by a partner service or the reply following this execution. (iii) The assignment of a value to a variable of the composition process.



The occurrence of an event e of the above types at time t is expressed by event calculus predicate Happens(e,t,ℜ(t1,t2)), (ℜ(t1,t2) defines the expected time range for t). Fluents signify system states as conditions over the values of specific variables of the composition process of a service-based system.

Figure 3: Example of instrumentation code for service replacement The instrumentation fragment in Figure 3 is inserted immediately after the first element in Figure 2. Thus, as a result of its execution in the beginning of the CRS process, any subsequent message exchanged with Payment Service (e.g., in Figure 2) will be automatically directed to the new endpoint reference. An example of instrumentation code fragment that allows for dynamic service substitutions as requested by the SCS manager (type c instrumentation) is shown in Figure 4. This fragment includes: (i) a activity that allows the composition process of CRS to accept substitution notifications from the SCS manager (in this instance for the payment service), and (ii) the actual substitution of the partnerLink for the payment service (see the activity in Figure 4). Instrumentations of type (a) are realised by placing the whole SCS composition process inside a BPEL4WS element and adding an onAlarm handler. The code for this instrumentation is not shown here due to space limitations.

(R1) (∀ t1, t2:Time) Happens(ic:PS:capture(oID1, cID, a), t1, ℜ(t1,t1)) ∧ Happens(ir:PS:capture(oID1), t2, ℜ(t1,t1+5*tu)) ∧ Initiates(ir:PS:capture(oID1), equalTo(CRes, "OK"), t2) ∧ Happens(ic:PS:capture_reverse(oID2,cID,a), t3, ℜ(t2, t2 + 50*tu)) ⇒ (∃t4:Time) (t3