Cloud computing is so big these days that I’m even getting emails from more or less reputable organizations imploring me to jump on the bandwagon and get rich off this latest fad. Clearly we’re well on our way if not already in the trough of disillusionment. As we pull out of the trough, we will have to deal with some very challenging issues – both technical and economic. On the technical side, I’ve been dealing with an interesting aspect of web services that I haven’t heard much about before, and that is the extent to which the service provider can help the client understand the scope of possible inputs for a given invocation. For example, let’s say a method accepts two inputs: An integer i which is supposed to be in the range 0 to 100, and an enumeration s of strings: red, blue, and green. Web services are described by an XML file called the web services definition language (WSDL) which describes as well as possible exactly what is required on input and what you will get on output. A lazy service provider will tell you simply that i is an integer and s is a string. Let’s say I develop a web site that acts as a client to the service. The end user goes to my site and does stuff which results in me making web service invocations to the service provider.
When the client invokes the service, if i happens to be 120 the service will respond with an error – out of range. This error will have to be read and interpreted by a human (clearly they will not make the effort to describe all the possible error conditions in the WSDL) and the client must be reconfigured to send only values within the range 0 to 100. The next time the service is invoked with the value for s being Horace, and once again the service provider responds with an error – s must be only one of red, green or blue. So once again the client is configured to send only the correct values for s.
Now this is a lazy service provider, but let’s say the service provider actually told me a priori that i is confined to the range 0 to 100 inclusive and that s must be either red, green or blue. Unfortunately, what the service provider neglected to mentionis that when s is green, i must be within the range 47 to 73. So once again, I have to change my client to accommodate this new rule.
If this seems like a horribly contrived scenario think again – when implementing a web service it is not always clear what rules apply. It may be especially difficult to configure legacy applications as web services because the rules are not necessarily captured in a convenient format. Even if they are, the developers are often behind schedule and in a rush to go live with the services so they may skimp on proper documentation and proper schema structure. And even if everything is done properly it is difficult to capture dependence rules such as s==green implies 47<=i<=73. As the number of independent variables increases, the number of invalid combinations may increase exponentially, to the point that it is impossible to convey the complete set of validation rules in a schema. Even if they are captured, the schema could become so complicated that a mere human would no longer be able to read and understand them any more.
Finally there is the issue of configuration changes on the server. If the administrator decides to add a fourth color orange to the enumeration, we can augment the schema to reflect the addition in the next version of the published WSDL. But if the constraints change because of a modification that a user has made, then you can no longer tell the client developer what the current constraints are by updating the WSDL. The WSDL should remain constant. If not, you would have a very hard time writing a client that works reliably. Is this scenario reasonable? Absolutely. There is an entire class of applications whose constraints will change as the data inside them changes. I suspect that most applications exhibit this behavior. One example is state transitions: You can transition only to valid next states. Another example is the class of applications is what we call ERP systems. ERP systems such as PeopleSoft intermingle user data with administration data – in fact, that is one of their strengths. It’s also one of their greatest weaknesses, especially when it comes time to upgrade an application. I’ve heard horror stories of companies that require 6 months or more to do an upgrade because of the complexities involved when administration and user data are intermixed.
So, is there a way to reliably inform a client about what the current constraints are? One possible solution is to convey to the client exactly what constraints will be applied in advance of every method invocation. You can do this with so-called RESTful interfaces where the complete state of the object is sent to the client, the client manipulates the object, and sends it back to the server. Along with the current state of the object you can also send the constraint information. It’s not a perfect system because you will have trouble describing co-dependent constraints (if you change s to green then i is further constrained to the range 47 to 73) and between the time the client requests an object and when it sends the object back the system may have changed in a way that invalidates the previously assumed constraints. But it’s better than nothing.