Service Level Agreement Comparison in Cloud Computing

Transcription

1 Volume-4, Issue-3, June-2014, ISSN No.: International Journal of Engineering and Management Research Available at: Page Number: Service Level Agreement Comparison in Cloud Computing Ritu Juneja 1, Dr. Deepti Sharma 2 1 M.Tech Student, Computer Science Department, Advanced College of Technology & Management, Palwal, INDIA 2 Head of department, Computer Science Department, Advanced College of Technology & Management, Palwal, INDIA ABSTRACT Service level agreements (SLAs) are one of the major considerations for every buyer of cloud computing services. Finding the SLA truth, and whether a service provider will meet your requirements, depends on the details of how they define their SLA measures and penalties. Our study indicates that none of the surveyed cloud providers offer any performance guarantees for compute services and leave SLA violation detection to the customer. We then provide guidance on how SLAs should be defined for future cloud services. This paper surveys the state of practice in service level agreement specification and offers guidelines on how to assure that services are provided with high availability, security, performance, and other required qualities. In addition, this paper discusses the quality properties that have been expressed in service level agreements. Keywords- Cloud computing, SLA, SOA. I. INTRODUCTION Cloud computing [1] is the new trend of computing where readily available computing resources are exposed as a service. These computing resources are generally offered as pay-as-you-go plans and hence have become attractive to cost conscious customers. Apart from the cost, cloud computing also supports the growing concerns of carbon emissions and environmental impact since the cloud advocates better management of resources. We see a growing trend of loading the previously in-house service systems to the cloud, based primarily on the cost and the maintenance burden. Such a move allows businesses to focus on their core competencies and not burden themselves with back operations. Cloud is defined as both the applications delivered as services over the Internet and the hardware and systems software in the data centers that provide those services [1]. According to this definition delivery of application as services (SaaS - Software as a Service) over the Internet and hardware services (IaaS - Infrastructure as a Service) are both parts of cloud computing phenomena. From hardware service(utility computing) point of view, there are few new aspects in cloud [1], the most prominent being the illusion of infinite computing resources and the ability to pay for use of computing resources on a short-term basis as needed. As consumers move towards adopting such a Service- Oriented Architecture, the quality and reliability of the services become important aspects. However the demands of the service consumers vary significantly. It is not possible to fulfill all consumer expectations from the service provider perspective and hence a balance needs to be made via a negotiation process. At the end of the negotiation process, provider and consumer commit to an agreement. In SOA terms, this agreement is referred to as a SLA. This SLA serves as the foundation for the expected level of service between the consumer and the provider. The QoS attributes that are generally part of an SLA (such as response time and throughput) however change constantly and to enforce the agreement, these parameters need to be closely monitored [2]. Due to the complex nature of consumer demands, a simple "measure and trigger" process may not work for SLA enforcement. Four different types of monitoring demands made by consumers are mentioned in [3]. One scenario is a consumer demands the data exposed by a service provider without further refinement such as transaction count, which is a raw metric. Second scenario is consumer requests that collected data should put into meaningful context. This scenario creates the requirement for a process which collects data from different sources and applies suitable algorithms for calculating meaningful results. Such metrics include statistical measures such as average or standard deviation that need to be computed from a raw set of numbers. The third scenario is the consumer requests certain customized data to be collected. In the fourth scenario the consumer even specifies the way how data should be collected. Both the latter mentioned scenarios imply an advanced consumer who would have a knowledge of the inner workings of a provider and somewhat rare in practice. Other issues such as trust also need to be considered during SLA enforcement. For example consumers may not completely trust the certain measurements provided solely by a service provider and regularly employ third party mediators. These mediators are responsible for measuring the critical 126

2 service parameters and reporting violations of the agreement from either party. We believe the upcoming trend of cloud computing is an extension of the SOA paradigm and the above mentioned issue of striking a balance applies to the cloud as well. The process of managing the provider-consumer agreements in computing clouds closely resemble the generic provider-consumer agreement process we mentioned above. Hence we propose an architecture for managing cloud consumer and provider SLAs, based on the WSLA specification [3]. We highlight two reasons to justify the importance of this research. 1. The most prominent cloud provider, Amazon EC2, puts the burden of proving SLA violations on the consumer. i.e. the consumer should take steps to enforce the SLA [4]. Having a formalized SLA enables the setup of the enforcement process to be automated and hence relieves consumers from that burden. 2. We believe the work that significantly intersects with ours is [5] where WSLA has been used as a base for grid service monitoring. However computing grids are very different from computing clouds in terms of 1) business model, 2) architecture, 3) resource management, 4) programming model, 5) application model and 6) security model [6]. Hence we believe applying WSLA to the cloud context would be a significantly different effort from the previous work. To the best of our knowledge this is the first use of WSLA in the context of cloud computing. Quality attribute requirements play an important role in service selection in service-oriented architecture (SOA) environments. SOA is an approach for designing, developing, deploying, and managing systems that are characterized by coarse-grained services that represent reusable business functionality. These systems serve consumers that compose applications or systems using the functionality provided by these services through standard interfaces. A very common technology for SOA implementation is web services, in which service interfaces are described using the Web Services Description Language (WSDL), and Extensible Markup Language (XML) payload is transmitted using SOAP over Hypertext Transfer Protocol (HTTP). A set of additional web service specifications (e.g., WS-BPEL, WS-Security, and WS- Reliable Messaging) can be used in this context to support operations such as service orchestration and management and qualities such as security and availability. Service-oriented systems have gone through a gradual evolution. Their first generation was based on monolithic components that could be reconfigured at compile time. Currently, their second generation is based on vertically integrated components that can be adapted and reconfigured at installation time and, to some extent, at runtime. In the future, we will see an emerging third generation of service oriented systems that will be cross-vertically integrated, contextsensitive, and reconfigurable in an autonomic, ad hoc, and ondemand manner [IST 2006]. At design time during service selection, an architect of a first- or second-generation service-oriented system will search for services to fulfill some set of functionality. The architect will make the selection based on desired functional requirements as well as quality attribute requirements that are important to system stakeholders. These qualities will probably be described in a service level agreement (SLA). In the case of third-generation, service-oriented systems, this service selection will likely occur at runtime, and the SLA will need to be in a machine-readable format that can be interpreted at runtime. An SLA is part of the contract between the service consumer and service provider and formally defines the level of service. It is the Service Level Agreement (SLA) that defines the availability, reliability and performance quality of delivered telecommunication services and networks to ensure the right information gets to the right person in the right location at the right time, safely and securely. The rapid evolution of the telecommunications market is leading to the introduction of new services and new networking technologies in ever-shorter time scales. SLAs are tools that help support and encourage Customers to use these new technologies and services as they provide a commitment from SPs (Service Providers) for specified performance levels [TM Forum 2008]. Organizations seek to develop SLAs for various reasons. From a simple perspective, an SLA is developed between two parties to spell out who is responsible for what, what each party will do, and sometimes more importantly what each party will not do. From a business perspective, an SLA is developed for these reasons: New commercial services entering a competitive market can use SLAs to establish themselves as reliable providers and hence attract customers. Service interactions across organizations increasingly permeate business processes and become critical to fulfilling business goals. SLAs establish a commitment to quality levels required by service users and providers to interact effectively. Moreover, SLA management helps customers validate and supervise the quality of services through scheduled and onexception reports. In one vision of the future, standardized services will be offered by multiple service providers. For example, realtors provide many different levels of service to home sellers, and all must provide a minimum level of service. That minimum service might offer use of the Multiple Listing Service (MLS) for the home at the cost of 1% of the home s posted sale price. As part of enhanced service, the realtor might actively market and handle the sale for the owner at the cost of 6 or 7% percent of the home s final sale price. In the context of web services, standardized services may be offered for common well-defined tasks such as tax return preparation, credit history requests, insurance claims, and banking. A common SLA that applies to a standard service is an important quality management artifact for service users and the regulatory agency responsible for overseeing the service. Many organizations provide services that depend on services from other organizations. For example, an online travelbooking system may interact with (1) banks to authorize credit cards, (2) hotel chains to check availability and reserve rooms, (3) airlines for checking and booking flights, and (4) car rental companies. In addition, each organization providing a service may, in its turn, use services from other organizations (commonly called layered or composite 127

3 services). In some situations, the unavailability or poor performance of one of the services may compromise the whole customer experience. In a multi-party composite service situation, SLAs can be used to identify the party that is responsible in case of a problem. The goal of this technical note is to provide an overview of the state of the practice in the development and management of SLAs in the context of SOA. We survey this state regarding SLAs in SOA environments mainly web services and offer guidelines to organizations that plan to contract external services or move to the third generation of service-oriented systems where SLAs in machine readable format become enablers. In this paper, we consider important questions such as: Currently, what mechanisms can be used to ensure quality of service (QoS) by contract? What quality attributes can be expressed in SLAs? What mechanisms are used by service providers to achieve and monitor those quality attributes? What technology support such as tools, specifications, and standards is available to express quality requirements, and what support will be considered in the future? II. BACKGROUND OF SLAs SLAs have been used in IT organizations and departments for many years. The definition of SLAs in a SOA context is more recent but is becoming extremely important as serviceoriented systems are starting to cross organizational boundaries and third-party service providers are starting to emerge. The current state of the practice for SLAs in an SOA context is heavily influenced by the IT management processes and procedures guiding SLAs. As background for the rest of the report, in this section we look at SLAs in IT organizations and SOA environments and at qualities that can be specified in the SLAs that are associated to services in SOA environments. IT SLAs SLAs have been used for many years in IT organizations and departments to identify the support requirements for internal and external customers of IT services. In this context, an SLA sets the expectations of both the IT service consumer and provider. It is common for IT service providers to deliver services at different levels of quality based on the cost paid for a service. An SLA is valuable for helping all parties understand the tradeoffs inherent between cost, schedule, and quality because their relationship is stated explicitly. As with any type of contract, the existence of an SLA cannot guarantee that all promises will be kept, but it does define what will happen if those promises are not kept. An SLA cannot guarantee that you will get the service it describes, any more than a warranty can guarantee that your car will never break down. In particular, an SLA cannot make a good service out of a bad one. At the same time, an SLA can mitigate the risk of choosing a bad service [Allen 2006]. A good service is one that meets the needs of the service customer in terms of both quality and suitability. A properly specified SLA describes each service offered and addresses how delivery of the service at the specified level of quality will become realized which metrics will be collected who will collect the metrics and how actions to be taken when the service is not delivered at the specified level of quality and who is responsible for doing them penalties for failure to deliver the service at the specified level of quality how and whether the SLA will evolve as technology changes (e.g., multi-core processors improve the provider s ability to reduce end-to-end latency) IT SLAs are enforced by service management processes and procedures. An example framework for IT service management (ITSM) is the Information Technology Infrastructure Library (ITIL), which has been widely used since the mid 1990s. The ITIL focuses on the activities involved with the deployment, operation, support, and optimization of applications. Its main purpose is to ensure that deployed applications can meet their defined service levels [Allen 2006]. The ITIL provides several key practice areas for ITSM. Below, we briefly describe the relationships between a subset of these areas that are relevant to SLAs: Service level management (SLM) is the main practice area for managing and maintaining QoS. This process area focuses on improving the QoS by continuously reviewing the quality of the services provided by an IT organization. SLM provides input to all service management processes and receives input from service support processes. The change management process area focuses on managing change in an efficient and consistent manner. It provides input to SLM on how infrastructure changes can affect QoS. The incident management process area s main purpose is to minimize the disruption that incidents cause to a business. It provides input to SLM on violations to agreements, who should be notified, historical data and trends, and any other actions that may be needed. The configuration management process area s main purpose is to identify, verify, control, and maintain configuration items. This area is also responsible for managing the relationships between configuration items. It identifies the services affected by problems with configuration items and provides this information to SLM. The capacity management process area s activities include monitoring, analyzing, tuning, and reporting on service performance to produce SLA recommendations. SLAs for IT typically fall into three categories: 1. Basic a single SLA with well-established metrics that are measured and/or verified. The collection of these metrics is typically done manually. 2. Medium the introduction of multi-level quality based on the cost of the service. The objective is to balance the levels of quality and cost. Automatic data collection enables comprehensive reporting to IT managers and stakeholders. 3. Advanced dynamic allocation of resources to meet demand as business needs evolve 128

4 Qualities That Can Be Defined in an SLA In theory, it is possible to specify any quality in an SLA, provided that all parties understand how to measure or verify its achievement. We ve seen two categories of qualities that can be specified in SLAs: measurable and unmeasurable. Measurable qualities can be measured automatically using metrics; for example, the percentage of time a system is available. Unmeasurable qualities are those that cannot be measured automatically from a given viewpoint; for example, determining the cost of changing a service (modifiability) is difficult to automate [Dobson 2005]. Measurable Qualities Accuracy is concerned with the error rate of the service. It is possible to specify the average number of errors over a given time period. Availability is concerned with the mean time to failure for services, and the SLAs typically describe the consequences associated with these failures. Availability is typically measured by the probability that the system will be operational when needed. It is possible to specify the system s response when a failure occurs the time it takes to recognize a malfunction how long it takes to recover from a failure whether error handling is used to mask failures the downtime necessary to implement upgrades (may be zero) the percentage of time the system is available outside of planned maintenance time Capacity is the number of concurrent requests that can be handled by the service in a given time period. It is possible to specify the maximum number of concurrent requests that can be handled by a service in a set block of time. Cost is concerned with the cost of each service request. It is possible to specify the cost per request the cost based on the size of the data cost differences related to peak usage times Latency is concerned with the maximum amount of time between the arrival of a request and the completion of that request. Provisioning-related time (e.g., the time it takes for a new client s account to become operational) Reliable messaging is concerned with the guarantee of message delivery. It is possible to specify how message delivery is guaranteed (e.g., exactly once, at most once) whether the service supports delivering messages in the proper order Scalability is concerned with the ability of the service to increase the number of successful operations completed over a given time period. It is possible to specify the maximum number of such operations. Unmeasurable Qualities Interoperability is concerned with the ability of a collection of communicating entities to share specific information and operate on it according to an agreed-upon operational semantics [Brownsword 2004]. It is possible to specify the standards supported by the service and to verify them at runtime. Significant challenges still need to be overcome to achieve semantic interoperability at runtime. Modifiability, in this context, is concerned with how often a service is likely to change. It is possible to specify how often the service s interface changes Implementation changes Security is concerned with the system s ability to resist unauthorized usage, while providing legitimate users with access to the service. Security is also characterized as a system providing non-repudiation, confidentiality, integrity, assurance, and auditing. It is possible to specify the methods for authenticating services or users authorizing services or users encrypting the data III. AREAS COVERED BY SLAS Cloud hosting and SLAs may provide protection at several different levels across infrastructure operating systems, and applications. Below are several of the important coverage levels that may be covered by a cloud SLA. Facilities-level SLA In a traditional colocation contract structure, the colocation provider will typically offer an SLA covering the data centre facilities required to support the client-owned hardware. These include items such as power, on-site generators, cooling, etc. This type of coverage is generally considered the bare minimum in the hosting market. A cloud service provider (CSP) will typically choose a colocation facility that maintains a facilities-level SLA. Platform-level SLA The next level of protection in a public cloud hosting agreement typically covers physical server, virtualization platform and network hardware owned by the cloud service provider and used by the cloud hosting client. Typically, the physical server and virtualization software are covered by a Platform SLA. The cloud network (network between Cloud Servers) may be covered by a separate availability SLA. Operating system SLA The operating system (OS) is the next potential area of coverage for a cloud hosting SLA. Cloud Service Providers offering an OS-level SLA typically provide some degree of managed services to a client. This additional service allows the vendor to guarantee that the operating system is properly maintained so that it is consistently available, and typically has some caveats Application-level SLA This type of SLA provides protection against application level failures up to and including the custom application running on the provider s hardware. This type of SLA is extremely rare in the cloud hosting market. Under this model, the cloud hosting provider is guaranteeing the availability and performance of their client s software, which is a difficult commitment to meet. IV. PENALTIES FOR SLA VIOLATIONS After a contractual threshold of downtime has been reached, most cloud providers will commit to a percentage 129

5 refund of the fees paid for a given period of time (generally monthly). Be certain to carefully compare the time durations and associated percentage of fees the provider agrees to refund in the event of an outage. Providers definitions of an SLA violation vary widely, and clients need to review them carefully to ensure that penalties paid under various SLAs are comparable. To compare accurately, be certain you understand the following: The amount of downtime allowed under the SLA and associated credit amounts At what amount SLA refunds are capped (i.e. how much of the fees paid for a given period is the provider obligated to refund) What portion of the fee is eligible for refund, for example: Will the provider only refund my compute related fees and exclude network, storage, CDN fees, etc., or is the credit against my entire invoice for the month? I f a server (or servers) fails with the result that my entire application fails, am I credited only for the server(s) that failed, for my entire invoice, or for the compute portion of my invoice? The answers to the questions above can greatly impact the usability and value of the SLA to your business, so ensure that you understand the level of commitment the provider is offering under its SLA. V. SLA COMPARISON Weak Uptime Guarantees for Compute The considered cloud providers offer only weak uptime guarantees for running VMs and do not explicitly specify uptime guarantee on a per instance basis. Amazon EC2 and Terremark vcloud Express only offer uptime guarantee on a per data center basis instead of per instance basis. Arguably, the chance of a data center being unavailable is much lower than per instance. Rackspace Cloud Servers and Storm on Demand implicitly provide SLA guarantee on per instance basis. Azure Compute provides uptime guarantees as an aggregate over all instances instead of per instance basis. No Performance Guarantees for Compute None of the considered cloud providers offer any performance guarantees for compute instances. As a consequence, a customer can only hope for its instances to receive the provisioned CPU, memory, network, and disk resources. Lack of performance guarantees may be unacceptable in enterprise clouds. Customer Should Detect SLA Violation The considered cloud providers leave the burden of detecting SLA violation on the customer which may be unacceptable for enterprise. Verizon, an enterprise Internet connectivity provider, detects SLA violations for its dedicated Internet service [20]. Service Credit Service credits for SLA violation offered by Amazon EC2, S3, and Terremark vcloud Express can only be applied towards future payments of respective cloud services. Amazon EC2 and S3, Azure Compute and Storage, and Terremark vcloud Express only partially reimburse the total cost of affected services, while Rackspace Cloud Servers and Storm on Demand can provide up to 100% reimbursement. Storm on Demand is unique, in that it offers to reimburse 1000% of the cost of affected instances. However, it is relatively a new IaaS provider. SLA Violation Reporting Time Period Azure Compute and Storage and Storm on Demand SLAs stipulate that a customer must report the SLA violation incident within five days of the incident occurrence which is more stringent than the 30 day violation reporting and claim filing time period offered by other cloud providers. Azure does allow a customer to file a claim 30 days after reporting the incident. SLA Jargon An SLA is a legal document and is the sole remedy for a customer for any service violations. The lack of standardization in SLAs and the use of SLAs as a potential marketing vehicle makes it difficult to compare SLAs of different cloud providers. As an example, Storm on Demand, and Rackspace guarantee their data center network, HVAC, and power to be 100% of the time, but they qualify it with scheduled maintenance. Similarly, Azure Storage performance guarantee does not include the time it takes to transfer the data in and out of data center. For a designer of cloud application, it is important to pay attention to these details. Storage SLAs: Performance vs. Request Completion For the storage SLAs, only Azure provides a performance guarantee per transaction, i.e., processing time for a request (which excludes the data download or upload time). Amazon S3 and Rackspace Cloud Files do not provide any performance guarantees and instead only provide a request completion guarantee. SLAs Offered By Business Internet Providers We briefly describe the Internet Dedicated SLA offered by Verizon [20] and how it compares with SLAs offered by cloud providers. Verizon Internet SLA comprises of nine service guarantees such as availability, latency, network packet latency, ticket response time for denial of service, and time to repair. Unlike SLAs of cloud providers considered in this paper, the onus for detecting SLA violation for certain metrics such as availability is on Verizon. However, a customer must explicitly request a service credit within 30 days of the incident occurrence. Scheduled maintenance is excluded from the service guarantee calculation. A customer account is then automatically credited for any service violation which is not the case with any of the considered cloud provider SLAs. What is missing from the SLAs? The SLAs of the considered cloud providers only focus on availability or request completion rate. An enterprise cloud SLA encompasses much more than availability, request completion rate, or performance. It defines guidelines for disaster recovery, privacy, auditability, and security. The details of which service guarantees to consider for enterprise cloud SLAs can be found in cloud computing use cases paper [9]. Further, unlike the public cloud providers considered in this paper, the burden of detecting SLA violation may lie on the provider. 130

6 VI. FUTURE OF CLOUD SLAS In this section, we consider how a cloud provider may define SLAs for cloud services in the future. Service guarantee: The considered cloud providers only provide uptime guarantees for IaaS services. The cloud providers may also want to offer other guarantees such as performance, security, and ticket resolution time. Providing a performance guarantee becomes necessary if cloud providers oversubscribe the resources of physical servers to decrease the number of physical servers used and increase their utilization. The over-subscription of the physical servers implies that performance of virtual machines running on physical servers may become a concern. Further, co-location of a virtual machine with other workloads may also impact the CPU, disk, network, and memory performance of a VM. Moreover, enterprises purchasing cloud based services may demand a minimal level of performance guarantee. Therefore, it may be necessary for a cloud provider to offer performance based SLAs for its IaaS compute services with a tiered pricing model, and charge a premium for guaranteed performance. Service guarantee time period and granularity: The service guarantee time period and granularity determine how stringent is the underlying service guarantee. A service guarantee is stringent if the metric is performance based for a fine-grained resource over a small time period, e.g. 99.9% of memory transactions in a five minute interval must complete within one micro second. Such a stringent guarantee can be loosened by aggregating the service guarantee over a group of resources (e.g., aggregate uptime percentage of all instances must be greater than 99.5%). Providers can use a combination of service guarantee granularity and service guarantee time period to price their services appropriately. For enterprise and mission critical workloads, a cloud provider may have no choice but to provide finer service guarantees. Service violation detection and credit: None of the considered providers automatically detect SLA violation and leave the burden of providing the violation proof on the customer. This aspect may not be acceptable to customers with mission critical or enterprise workloads. A cloud provider can differentiate the pricing of its offering if it automatically detects and credits the customer for SLA violation. However, the tooling cost to automatically measure, record, and audit SLA metrics can be a concern. Outcome based SLAs: The cloud providers considered in this paper offer IaaS and PaaS services. Using these services, a customer can deploy her own applications in the cloud. However, in the future, cloud providers may offer outcome based services on top of cloud, where a provider delivers a complete solution for a customer using cloud. For outcome based services, a cloud provider needs to define SLAs for the promised outcomes and how those SLAs map to the underlying IaaS and PaaS infrastructure it provides. Standardization of SLAs: The lack of standardization in cloud SLAs makes it difficult for a customer to effectively compare them. As cloud services mature, and as the vision of utility computing is realized, the standardization of SLA is likely to take center stage. Structured representation of SLAs (e.g., in XML) may be necessary for standardized SLAs. VII. CONCLUSION As discussed in this paper, there is much more to a provider s cloud SLA than simply an uptime percentage guarantee, and savvy buyers need to investigate their options carefully to ensure that they are comfortable with the guarantee offered by their provider. All cloud providers leave the burden of providing evidence for SLA violation on the customer. We then discussed how SLAs should be defined for future cloud services. As more and more consumers delegate their tasks to cloud providers, Service Level agreements (SLA) between consumers and providers emerge as a key aspect. This study will help in clarifying and defining SLAs of existing and future cloud based services. REFERENCES [1] Armbrust, M., Fox, A., Gri_th, R., Joseph, A.D., Katz, R.H., Konwinski, A., Lee, G., Patterson, D.A., Rabkin, A., Stoica, I., Zaharia, M.: Above the clouds: A berkeley view of cloud computing. Technical Report UCB/EECS , EECS [2] Department, University of California, Berkeley (Feb 2009) [3] Keller, A., Ludwig, H.: The wsla framework: Specifying and monitoring service level agreements for web services. J. Netw. Syst. Manage. 11(1) (2003) 57{81}. [4] Ludwig, H., Keller, A., Dan, A., King, R., Franck, R.: Web service level agreement (WSLA) language speci_cation. IBM Corporation (2003) [5] Amazon: Service level agreement for ec2 (2008) [6] He, C., Gu, L., Du, B., Li, Z.: A WSLA-based monitoring system for grid service-gsmon. In: 2004 IEEE International Conference on Services Computing, 2004.(SCC 2004). Proceedings. (2004) 596{599} [7] as of 12/11/2012 [8] aspx?id=24434, as of 12/11/12 [9] as of 12/11/2012 [10] docs/w/wiki/service-level-agreement.aspx, as of 12/11/2012. [11] [Allen 2006] Allen, Paul. Service Level Agreements. Hhttp:// cure/interact/ /service_level_agreements.php&area=silverh (2006). [12] [Andrieux 2007]Andrieux, Alain, et al. Web Services Agreement Specification (WS- Agreement).Hhttp:// (2007). [13] Copyright Vandana Publications. All Rights Reserved. 131