Web Services Pitfalls
by David Orchard |

Provisioning

The process of adding a user to a system, typically called provisioning, must also be addressed. In the travel reservation service example, user information must be entered into the reservation service: seat preferences, meal preferences, frequent flyer numbers, preferred alliance partners for flight selection, billing address, shipping address for the ticket, credit card information. For each user that can use the service, information needs to be entered. There can also be complications, where the price of the ticket is dependent upon the company that the user is part of. Often larger companies negotiate discounted rates based upon their size.

Thus the ASP must provide a mechanism for providing user information, and typically these would be in an automated API manner. The developer integrating the service must also incorporate logic to provision the service for the user. This logic would presumably be executed once the user is authorized to use the service.

The service provider and consumer need a mechanism to exchange provisioning information, and the service provider must know who it trusts as a source of that user information. It’s hard to imagine this without a contract in place.

DLL Hell Magnified?

Last, there's the issue of service version control. Service providers change their interfaces and workflows. Perhaps the travel reservation service provider decides to add a parameter to the fare quote request, for example: the specification of whether an electrical port is required for a particular trip. Usually the ASP will provide a new interface for the parameter, and it probably won’t keep the old interface available. It is very difficult for ASPs to maintain backwards compatibility, and they often don’t. Their databases, business logic, have all changed, so they don’t want to keep the old stuff running. A typical example of this is the way that organizations often don't offer two different versions of an ERP system at the same time, using the same underlying data.

What happens to our client when the interface changes? Generally, the client code breaks. The ASP's interface is expecting another parameter in the middle step, and the client software isn’t providing it. In the worst scenario, the ASP simply changed the interface and didn’t give any advance warning to the client. This is what typically happens in the web service provider market today. When the interface changes, the clients break. The consumer must assign a developer to discover the new parameter, perhaps changing interface and logic to collect and pass on the parameter. Depending upon the complexity, the consumer’s service may be down for an unknown amount of time, perhaps weeks or months.

This seems a lot like DLL hell, only worse. In DLL hell, a new application on your desktop installs a new DLL that breaks one of your existing applications. In web services DLL hell, a service upgrade breaks an arbitrarily large number of services that are on many different and separate machines, outside of a firewall. The consumer of the service can’t download an update, uninstall, or re-install.

There is no technical solution even mentioned in any of the presentations on web services. The problem of upgrading services and how that affects existing client software is not treated in any way.

The only solution today is through the use of contracts. Typical wording in the contract will state that the service provider must give 60 days notice of interface change, with test accounts available for testing available within 30 days.

But even then, each and every client must upgrade. The consumer simply has more warning. The key message though is that part of the contract between the service provider and the consumer is the treatment of versioning of interfaces.

What’s it all mean?

I’ve described some of the real-world issues of web service integration, particularly contract negotiation, billing, security, provisioning, version control. I’ve skipped other important issues like quality service, monitoring and support. But it turns out that any real and useful web service must provide some specification of these capabilities. It is unlikely that the service provider will simply provide these to the general world via a public registry. I expect that for quite some time, services will be offered via a private catalog. There will be a fairly extensive and human-centric process that occurs before data and information is entered in the catalog on behalf of consumers and service providers. The specifications for the various capabilities are also collected during this negotiation process. Consumers can then trust the validity of the catalog, and service providers can trust that consumers have been validated. Further consumers can go to one place to find all the information, rather than n different service providers. And Service Providers can update only one place, rather than m consumers.

Building an ecosystem of integrated web services is much more complex than the examples often suggest. There are many characteristics that must be accounted for, with contractual policies in place. The hypesters often don’t address these issues when describing web services, but they exist nonetheless.

The real summary is that web services will be used as an enabling technology to integrate applications together more quickly and easily. There are real-world integration problems that are being solved by web services standards compliant products and deployments. It will be quite some time, if ever, before there is widespread adoption of standalone web services that are usable without significant human intervention and contract negotiation.

Prev  [1] [2]