Service Level Agreements

Organizations that employ a Web services approach, especially where they pay for the services, will demand a service level agreement. Service level agreements are formed between two parties and state how services will be used and accounted for and any prerequisites for use. This can become a way for providers of services to distinguish themselves from competition in today's competitive marketplace. Service level agreements in the Web services model can take many forms. The typical written contract has merit for two parties who have prior established relationships. Two parties that are dynamic and learned of the service offering dynamically may agree to handle contractual details through electronically signed contracts and certificates.

A typical (basic) service level agreement covers the following points:

• Starting and ending dates of the contract (e.g., September 10, 2003, through September 10, 2005)

• Availability of the service (e.g., Monday through Friday, 8:00 a.m. to 8:00 p.m., Eastern Standard Time)

• Performance/response time (e.g., 70% of all transactions shall execute within four seconds)

• The type of contract (e.g., unlimited usage, restricted usage during peak times, ad hoc)

• Limitations (e.g., one hundred transactions per day)

• Security (e.g., use of certificates for identity, encryption, and signing)

• Auditing (e.g., monthly reports online at close of last business day)

A detailed service level could include actions the service provider and client would take in case of failure. Providers may also impose limits on the maximum and average response times for notifying a client of downtime or planned outages. Service level agreements may specify penalties if the provider fails to meet defined objectives over the duration of the agreement. An agreement may also provide for the client to terminate for unsatisfactory resolution of problems related to availability, reliability, performance, and security.

To guarantee that your Web service will stand up to whatever service levels you attach to it requires good quality assurance and testing. Table 16.2 is a checklist of Web service features that should be tested. This list is by no means complete but should provide you with a start for offering Web services to paying consumers. In the future, consumers will demand an appropriate service-level agreement before using your Web service. Ideally, your organization will employ automated testing tools, by vendors such as Empirix, PushToTest, and RedAlert, to guarantee ongoing monitoring of compliance to the agreements.

Table 16.2: Web Services Features

Feature	Questions
Security	Can unauthorized users access any function not granted to guests? Can authorized users gain access to functions not explicitly assigned to them? Does the Web service adequately handle denial-of-service attacks?
Versioning	Does a newer version of your Web service also support older clients? Does the new version break any dependent Web services?
Timeout	What happens when a Web service times out? Is accounting information accurate when a service exceeds certain thresholds?
Performance	Does the Web service take longer to respond than its stated objective (e.g., five seconds)? What happens when the Web service is put under load?
State	Does the Web service respond correctly when you set a value in a stateful request on first and subsequent requests?
Infrastructure failture	Does the Web service dynamically discover new dependent services when a primary service is unavailable?