Modeling and monitoring SLA for service based ... - ACM Digital Library

Modeling and Monitoring SLA for Service Based Systems Ajaya Kumar Tripathy Department of CSE Silicon Institute of Technology Bhubaneswar, India

ABSTRACT A SLA (Service Level Agreements) is an agreement between the web service provider and web service user that specifies the guaranteed level of service quality and functional properties of a web service. A web service user can be assured of the guarantee terms specified by the SLA. A SLA monitoring framework is used to specify and monitor the SLAs so as to ensure the guarantee terms. Several SLA frameworks have been proposed, but most of them involve lot of manual efforts and technical expertise. Generally SLAs are specified and negotiated by the business analyst at management level. Most of the time the business analysts don’t have such technical skills. The goal of this paper is to design a new SLA monitoring framework for specifying and monitoring SLA guarantee terms with little intervention of skilled people.

Categories and Subject Descriptors H.3.5 [Web-based services]: Web-based services

General Terms Verification, Languages, Design

Keywords Service Based systems, Requirements Monitoring, Service Level Agreement

1. INTRODUCTION A web service is an application that exports a description of its functionality and makes it available through standard network technologies. These functionalities can be accessed through standard XML messages over a network [23]. Research on Web Services spans over many interesting issues covering all phases of the service life-cycle: e.g. service description, service discovery, selection and invocation, service composition, service advertisement, service negotiation, service security and reliability. In this paper, we focus on another very interesting research topic: SLA specification and monitoring.

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. ISWSA’11 April 18-20, 2011, Amman, Jordan. Copyright c 2011 ACM 978-1-4503-0474-0/04/2011 ...$10.00.

°

Manas Ranjan Patra Department of Computer Science Berhampur University Berhampur, India

The ability to set up and monitor SLAs has been increasingly recognized as one of the essential preconditions for the deployment of web-services [16]. SLAs are set through collaboration between service consumers and service producers in order to specify the terms under which a service that is offered is to be deployed and the quality properties that it should satisfy under these terms. The ability to monitor the compliance of the provision of a service against a service level agreement at runtime is crucial both from the point of view of the service consumer and the point of view of the service producer. For service consumers, monitoring service level agreements is necessary due to the need to check if the terms of an agreement are satisfied, identify the consequences that the violation of certain terms in an agreement, and claiming penalties for the violated service provision terms. For service providers, the monitoring of the provision of a service against the terms specified in an agreement is necessary in order not only to gather evidence regarding the provision which may be necessary if a dispute with a service consumer arises over the provision but also in order to identify prob- lems with the delivery of the service and take action before an agreement is violated. Service providers can make use of SLA technology to advertise and offer their services capabilities while consumers are able to formalise their service level objectives through SLAs. It is in the interests of both parties to create and operate SLAs with a minimum of human interaction on the one hand, but to agree upon legally binding electronic contracts and monitoring the contract on the other hand [10]. Several SLA monitoring frameworks have been proposed to cope with the SLA guarantee term specification and monitoring(see e.g. [8, 18, 4, 12, 19, 22]. Different framework have been developed their language for specifying guarantee terms, WSDL specification and business process specification of deployed services are used to identify the required events to specify the required guarantee terms. The frameworks is uses the specified properties, automatically collect the required events and monitor the guarantee terms. During SLA negotiation phase, both parties are using their knowledge and business assumption for maximizing their profit and value of the SLA at hand. Generally this task is done by business analyst of the participating organization. Using current existing SLA monitoring frameworks need lot of technical expertise, requiring a lot of manual effort, time-consuming, error-prone [8]. But generally business analysts don’t have such technical skills. So they need assistance of skilled labors for specifying, understanding and monitoring SLA guarantee terms. The aim of this paper is the formulation of a template

based SLA specification scheme (usage of which does not need to investigate WSDL specification or business process specification of the deployed service), and developing a tool to integrate this SLA specification with the deployed service and an existing run time web service monitoring framework. The rest of the paper is structured as follows. In Section 2 we describe the state of the art and in the Web Service Technology and existing research approaches to the monitoring of service based systems and SLA for web services. Section 3 defines the research need and objective for user friendly SLA modeling and monitoring. Section 4 describes the proposed research methodology for the research objective defined in previous section. Finally Section 5 concludes the work and describe our future direction of research.

2. STATE OF THE ART Web Service Technologies: Web Services are platform-independent, self-contained, selfdescribing, modular components that can be published, located and invoked over the Web. In order to achieve interoperability in such an heterogeneous framework, standards are of vital importance [15]. A whole stack of different standards has already been proposed with the aim of supporting the description, discovery, and interoperability of distributed, heterogeneous applications as services. The functional description of a Web Service is provided by the Web Services Description Language (WSDL) [9]. WSDL describes the set of operations it offers, in-going and outgoing messages, and data types used by the Web Service (defined in terms of XML Schemas). Concrete protocol bindings and physical address port specifications complete a service description, supplying a mechanism to locate the Web Service. WSDL defines what the Web Service does, not how it does it: it characterizes the service only in terms of its interface, without providing any behavioral description. Such dynamic aspects of the behavior are crucial in fully understanding what a service does in order to be recognized and used by autonomous applications. An orthogonal effort in the description of complex services has been made by the business and industrial world, with the proposal of low level process modeling and execution languages, like BPEL4WS (Business Process Execution Language for Web Services) [2]. BPEL4WS gained a lot of attention and support from the industry and has become the de facto standard. BPEL4WS provides an operational description of the stateful behavior of Web Services on top of the service interfaces defined in their WSDL specifications. A BPEL4WS description identifies the partners of a service, its internal variables, and the operations that are triggered upon the invocation of the service by some of the partners. Operations include assigning variables, invoking other services and receiving responses, forking parallel threads of execution, and nondeterministically picking one amongst different courses of actions. Standard imperative constructs such as if-then-else, case choices, and loops, are also supported. The BPEL composition model is recursive: a BPEL process, like any Web Service, supports a set of WSDL interfaces that enable it to be exposed and invoked as a regular Web Service. BPEL4WS can be used both for the publishing and for the execution of complex services: abstract BPEL processes can be used to publish the interaction protocol with external Web Services, while executable BPEL specifications can be used to implement the internal process, i.e., the part that is not visible to external services and that can be executed by

standard engines (e.g. the Active BPEL Open Engine [11] or the Apache ODE [1]). SLA Monitoring Frameworks: The necessity of specifying and monitoring SLA between web service providers and consumers is widely recognized by industry and academia [18, 12, 3, 5]. Lemana et al. [13] have proposed a approach for SLA modeling with the introduction of the language SLAng. This language is an extension to existing business process languages. In this language SLAs are defined as a list of Quality of Service (QoS) parameters. At the implementation stage QoS parameters are assigned to the target business process, this lead to a intrusive approach. The target servers requires to support these QoS parameters. This approach becomes less extensible and flexible. Same type of problem occurs if the SLA is implemented by a process. The approach described in [19] creates monitoring agents to monitor the business process. These agents instrument the business process by listening to its network usage. Another process evaluate the SLA for any change in the process. This approach require the business process to update constantly to adopt a new SLA requirements. Barsi et al [5] have proposed a approach for monitoring dynamic service composition with respect to guarantee terms expressed via assertions on services. This approach assumes composition process specified in BPEL. A guarantee term is verified by a call to an external service and the execution of the composition process waits until the monitor returns the result of the check. The composition process may continue or aborted with an exception notification on whether the guarantee term is violated. This approach is intrusive to the normal operation of an service based system. The monitoring that it perform may effect the performance of the monitored system. Another monitoring approach is presented by Baresi et al. [7]. This approach monitors both functional correctness of BPEL orchestration and quality of service agreements set between the service provider and the service consumer. They provide a language called WSCoL (Web Service Constraint Language) [6] which allows designers to specify constraints on BPEL orchestration. Appropriate external services called Monitoring managers are responsible for analyzing WSCoL constraints. The business logic is unaffected by monitor specification. Therefore, we can say the approach is non-intrusive at the specification time. But to allow the process to interact with the external monitors, additional BPEL code is added to the process at deployment time, this leads to an intrusive approach. Lazovik et al. [14] presents a framework in which service requests are presented in a high-level language called XSRL (Xml Service Request Language). The framework monitors the execution of the request services. Designers can define three kinds of properties: (1) goals that must be true before transiting to the next state (2) goals that must be true for the entire process execution, and (3)goals that must be true for the process execution and evolution sequence. The framework loops between execution and planning. The latter activity is achieved by taking into account context and properties specified for the state-transition system. This makes it possible to discover whether a property has been violated by the previous execution. IBM’s WSLA (Web Service Level Agreement) framework [12] was designed to enable the specification and monitoring SLA for web services. An XML based WSLA language [9]

is used to specify quality objective only (i.e., performance and throughput) with out covering functional requirement. WSDL defines the basic building blocks to model an SLA for web services. In the specification, each SLA references the web service as a whole. However, it can also refer composition of multiple web services. It is composed of a number of metrics, which measure different aspects of a service. The above approach claims to provide some degree of extensibility. For instance, complex matrices are composed by a no of other matrices. Chau et al. [8] propose a similar model with more extensible and flexible with the introduction of matric and Service Level Objective (SLO) libraries. This model refines the WSLA specifications: SLAs consist of multiple SLOs and use various metrics that indicate different measurement aspects of a process. SLA guarantee terms specified in terms of matrices. This approach has a matric library facility in which user can define basic matrices and reuse them to form complex matrices. Therefore this approach is more user friendly. But to define basic matrices user need the help of skilled labors. Once the basic matrices defined in the library, one can easily use this framework to specify and monitor complex guarantee terms. For defining the the basic matrices the user needs to know the business process specification. Barbon et al. [4] present a monitoring approach extending the open-source Active BPEL engine. This approach defines an executable monitoring language RTML (Run-Time Monitor specification Language) to specify guarantee terms, which is based on events and combines them exploiting pasttime temporal logics and statistical functionalities. Monitors run parallel to BPEL process as independent software modules. Verify the guarantee terms by intercepting the input or output messages that are received or sent by the process. This approach does not require to instrument the monitored services. Two different kind of monitors are supported by this approach: instance monitors, which verifies the execution of a single instance of BPEL process; and class monitors, which verifies aggregated behavior of all the instances of BPEL process. The framework support automatic generation and deployment of monitors using guarantee terms specified in RTML. This approach is a nice approach but as a user of this framework to specify the guarantee terms in RTML the user needs to understand RTML, the BPEL process specification and WSDL specification of the monitored service. Mahbub et al. [21, 18, 17] present an approach extending the WS-Agreement [3]. This approach supports monitoring of quality and functional property of service need to be monitored, introduces a new language to specify service guarantee terms in terms of:(1)events signifying invocation of operations of a service by the composition process of an SBS system and return from these executions. (2)events signifying calls of operation of the composition process of an SBS system by external services and return from those executions. (3)the effect that events of either of the above kind have on the state of the SBS system or the service that it deploys. This language has been defined by a separate XML schema and is called EC-Assertion, which is based on Event Calculus (EC) [20] which is a first order temporal logic language. This approach is efficient enough to handel broader range of functional and quality properties of services. But to use this technique user needs to understand EC, EC-Assertion and the business process specification of SBS system to understand the events.

Figure 1: Scenario

Online Train Ticket Purchase Service:

3. RESEARCH OBJECTIVES Problem Definition: A business analyst of a service provider organization can make use of SLA technology to advertise and offer its service capabilities while a business analyst of a service consumer organization can formalize its service level objectives through SLAs. Both the business analysts use their knowledge and business assumptions to maximize their profit. It is in the interest of both the parties to create and operate SLAs with minimum human interaction on one hand, but to agree upon legally binding electronic contracts and monitoring of the contracts on the other hand. Several SLA monitoring frameworks have been developed to cope with the SLA guarantee term specification and monitoring problems. But an important practical question that constantly arises is that none of them consider the skills of the actual user (business analyst: generally have preliminary IT skills) of the SLA monitoring framework. Use of existing SLA monitoring frameworks need highly skilled IT professionals on whom the business analysts become dependent. The issue can be better understood by considering some SLA guarantee terms which are specified using some existing approaches, namely; Astro Approach [4], Everest Approach [21, 18, 17]) for a simple example scenario. Example Scenario: Our reference example consists in providing a online train ticket purchase service, say the OnlineTrainTicketS service, which offer online train ticket booking service, by combining three separate, independent, and existing services: a price calculation service PriceCalculatorS, a online payment service OnlinePaymentS and a service that create train ticket CreateTicketS (see Figure 1). When OnlineTrainTicketS accepts requests for purchase train ticket it contact the PriceCalculatorS, it get back an cost. After obtaining the price, the OnlineTrainTicketS invoke the OnlinePaymentS for make the payment for the asked ticket. If OnlineTrainTicketS get back a payment success notification from OnlinePaymentS, the OnlineTrain TicketS terminates by sending a payment fail notification to the client, otherwise the OnlineTrain TicketS invoke the CreateTicketS to make the ticket. After getting the ticket from the CreateTicketS, the OnlineTrain TicketS send back the ticket to the client. The BPEL specification of OnlineTrainTicketS is defined in Appendix.

Even if the scenario is very simple, the client organization may want to specify following guarantee terms for their business goals: 1. Train ticket purchase process time must be less then 10 sec. 2. Payment process completion time must be less then 2 sec. 3. Average time taken by ticket purchase process should be less then 8 sec.

SLA guarantee terms Specification Astro Approach You can find the detailed description of this approach in [4]. Lets see how one can specify the above guarantee terms using Astro approach and identify the technical skills needed to use this approach. This approach uses RTML (Run-Time Monitoring specification Language) to specify the functional and quality properties of service based system (SBS). To specify the above mentioned SLA guarantee terms, first we have to investigate the BPEL specification of the process to identify the incoming/outgoing messages required to monitor the guarantee terms. For the first guarantee term the the messages required are: TrainTicketRequest (the incoming message to OnlineTrain TicketS) and TicketStatus (the outgoing message from OnlineTrainTicketS). For the second guarantee term the the messages required are: PaymentRequest (the outgoing message from OnlineTrainTicketS) and PaymentReply (the incoming message to OnlineTrainTicketS). For the third guarantee term the the messages required are: TrainTicketRequest (the incoming message to OnlineTrain TicketS) and TicketStatus (the outgoing message from OnlineTrainTicketS). After having this knowledge we can specify the above mentioned guarantee terms using RTML as follows: • Train ticket purchase process time must be less then 10 sec. time (¬ msg(OnlineT rainT icketS.output = T icketStatus) S msg(OnlineT rainT icketS.input = T rainT icketRequest) < 10s • Payment process time completion time must be less then 2 sec. time (¬ msg(OnlineT rainT icketS.input = P aymentReply) S msg(OnlineT rainT icketS.output = P aymentRequest) < 2s • Average time taken by ticket purchase process should be less then 8 sec. Average(time (¬ msg(OnlineT rainT icketS.output = T icketStatus) S msg(OnlineT rainT icketS.input = T rainT icketRequest)) < 8s As we see here the use of this approach need a good knowledge of BPEL specification and RTML.

Everest Approach You can find the detailed description of this approach in [18]. Lets see how one can specify the above guarantee terms using Everest approach and identify the technical skills needed to use this approach. This approach uses EC-Assertion(a event calculus based language) to specify the functional and quality properties of SBS. To specify the above mentioned SLA guarantee terms, first we have to investigate the BPEL specification of the process to identify the events required to specify the above guarantee terms. That is invocation of an operation in one of the partner service, invocation of an operation in composition process by one of its partner services and return from execution of an operation. Investigating the BPEL and WSDL specification we can identify the events required to specify the second guarantee terms as follows: ic : OnlineP aymentS : P ayment(I d, AccI nf o, C ost): Invocation of Payment operation in OnlinePayment service. ir : OnlineP aymentS : P ayment(I d): return from execution of Payment operation. After having this knowledge we can specify the above mentioned second guarantee terms using EC-Assertion as follows: (∀ I d, AccI nf o, C ost : string)(∃ t1 : time) Happens(ic : OnlineP aymentS : P ayment(I d, AccI nf o, C ost), t1 ,

BPEL Specification of OnlineTrainTicketS