Service Contracts

The barrier between Web Services as they currently exist and the promised future of run-time discovery lies primarily in the absence of contracts for the services. In this case the contract that is needed follows from Bertrand Meyer's work on design by contract and concerns low-level contracts between components in an object-oriented environment.^[104]

Design by Contract

The contracts we need for Web Services lie somewhere between the method-level assertions of design by contract and the high-level contracts that businesses enter into to do business with each other. As we described in Chapter 2, it is possible and desirable for a traditional contract to be expressed in semantic terms, and in so doing it becomes simpler to construct, less ambiguous, and easier to interpret.

However, the template that these contracts need to flow from has a different set of primitives than the intellectual property transfer contract that we looked at in Chapter 2. The key semantic concepts that must be defined to a level that a system could interpret include the following:

• Security—The security contract provisions will concern items such as assurance that information will be encrypted when transported, and the provisions will describe what level of authentication is needed and which categories of authorized users will be allowed access to what data. The security contract may also specify what information that was transported as part of the service invocation will be maintained by the producer and what rights the producer has to that information.

• Auditability—This set of provisions will concern whose responsibility it is to ensure that detailed records are kept of all interactions and whether these records need to be at the level of detail to support billing arrangements, security audit, quality-of-service audit, financial audit, or any other requirement.

• Service level agreements/quality of service—The provider will establish a set of quality-of-service metrics that will include such factors as capacity (in terms of number of messages by type to be handled per unit of time), response time (average time from message receipt to message reply), and availability (number of minutes of uptime guaranteed over particular windows: daytime, weekend, graveyard, etc.).

• Billing—Each service will potentially carry a billing component, typically a cost per handled request. The billing contract will also specify mode of payment (automatic deduct from bank, invoice, etc.) and frequency.

• Assertions and guarantees—These are on the content of the messages. For example, the service that provided arithmetic division might assert that the divisor must be nonzero. An inbound message with a zero as the divisor will obviate the service of any obligation other than that of posting an exception. For all messages with valid dividend and divisors, the service guarantees that the result when multiplied by the divisor will yield the dividend (within a set level of precision).

• Warrantees—In the event that a guarantee has been violated, this provision specifies the remedy (e.g., payment). Note that there will be warrantees on the Web Service, as well as warrantees on any referenced real-world service. For example, a wholesaler might warrantee that the site will be available 24/7 and credit a month's worth of transactions for any month where availability was less than 99.99%. The wholesaler might also have a warrantee that any item it claimed was available to promise was indeed available to promise, and that a credit of $x or x % would be allowed for every violation.

• Handling exceptions—This section spells out what actions each participant will take to detect exceptions and what each participant will do (in terms of messages to the other party) in the event of an exception.

For run-time discovery to work, these items (as well as others) will be needed and must be reduced to functions that can be evaluated by the system.

^[104]Bertrand Meyer, Object Oriented Software Construction. New Jersey: Prentice Hall, 1988, p 115.