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.