Contracts are important for Web services. Design by contract (DBC) is nothing new, but, unfortunately, formal precondition and postcondition specifications have never become mainstream, at least not in the way they were presented by Bertrand Mayer in Object Oriented Software Construction.

However, with the advent of Web services, I think it‘s time to re-introduce DBC to the mainstream. Here‘s why:

  • From a client‘s prospective, testing and debugging a Web services call is much costlier than a local method call. For example, service providers may restrict the number of calls per day in test environment, so trial and error may not be an option. So it is important for a client to be able to understand exactly what is required from the clients (precondition) and what is returned by the service (postcondition).
  • Web services can be exposed to a very wide range of clients that use different technologies. So it is important for service providers to be able to unambiguously define the contract with the clients to simplify error and exception processing by potentially separating (externalizing) validation logic from the service‘s business logic.

Preconditions and postconditions for Web services must support the following capabilities:

  • Validation of input and output parameters. This is partly addressed by the Schema, but that are many types of validations that can‘t be expressed using Schema, such as cross-field or cross-parameter validations (e.g., “endDate > beginDate“). Postconditions should also be able to validate the outputs relative to the inputs, e.g., “resultFlightDate>=requestedDate“.
  • Preconditions and postconditions should be able to validate the state of the service. Classical Meyer‘s example is a stack class with “remove“ operation where the precondition states the stack must not be empty. In Web services world, oftentimes there is a need to specify dependencies (so they would be clear to the clients) between calls to different operations, e.g., operation “b“ can only be called after operation “a“ was called. BPEL can do some of it but only on a very limited scale. And BPEL is not really a validation tool.
  • Precondition and postcondition checks can run on the server or on the client. In test environment it might be beneficial to run them on the client for faster development.

So what is the solution? I‘m hoping that at some point DBC will find its way into one of the numerous WS specifications. For example, there are some “traces” of DBC in the newly announced WS-Semantics. Although at this point WS-* specifications proliferate at such speed that I doubt that anyone can keep up with them (except, of course, vendors and standard organizations who keep churning them out) so it may do more harm than good.

So the easiest solution for the time being could be for service providers to actually develop client libraries that implement preconditions (and may be even postconditions). This will allow the clients to deal with APIs (and perhaps the source code) expressed in the language that they understand instead of having to deal with bare-bone WSDL which has to be translated into the target language anyway. These libraries can even include “stubbed” versions of the services that can run entirely on the client for testing purposes. Yes, it‘s more work for service providers, but, realistically, how many different languages/platforms are we talking here? In enterprise it probably boils down to various flavors of J2EE and .NET. There are also Python, PHP , Ruby and JavaScript for AJAX clients. For a commercial service provider, the cost of developing these fairly simple client libraries will be returned many times over by the added convenience for the clients. For an example, just look at pygoogle and other Python wrappers for popular Web services. Granted, this approach does not fully address my second requirement for state validation (although it can be done using a smart client library), but I think it‘s a good start nevertheless.

Tags: , ,

5 thoughts on “Design by Contract for Web Services

  1. Hi,

    Can you help me explain:

    Why Design by Contract between web services?

    Why verifying the combination of web services through the contract?

    thanks!

  2. Pingback: 3d webdesign
  3. I want to develop an automatic planner for composing web services exploiting their Pre/Postconditions. what is the correspondence or the relations to Design by Contract.

    Thanks and Best Regards

Comments are closed.