Last month we looked at some of the missing pieces in the Web services model as it currently exists, those being: Security, support for transactions, and the notion of a business process. We also debunked a commonly held view that Web services will allow one to easily turn legacy applications into components which can be accessed over the Web.
A fundamental assumption in the Web services model is that application components can be accessed over the Web in real-time to provide functions that one does not wish to build, and that these functions can be assembled or aggregated to produce a larger composite application.
This is essentially outsourcing at its most granular level. While this model may at a technical level actually be possible (once the limitations referred to above have been dealt with,) at a commercial level there are enormous challenges.
What happens in such a scenario if one of the components in the composite application fails? How would you even know which it is? And even if the chain has only one link, how are you going to manage a Service Level Agreement?
How will you monitor performance and manage service levels over an unreliable network such as the Internet? These are problems with one Web service provider. With more than one they become ever more complex to manage.
Better yet, why would you enter into an agreement with a party you have never seen just because you happened to find their Web service in a directory on the Internet? Do you today procure services based on a Yellow Pages ad? Well, why would you do so with Web services?
There are certain immutable laws of business and one of them is that people do business with people; relationships are of value! This is a key reason why B2B exchanges failed and it is a weakness in the Web services model in that it overlooks the value of trusted auditable relationships.
Let’s face it, when the **** hits the fan, its nice to know who is responsible. With composite applications composed of Web services it will be harder to know whose door to knock on.
More to consider
There is another aspect to composite applications composed of Web services that bears consideration in light of events of last year. How much risks are you willing to entertain in assembling applications from providers found in a public directory?
How do you know that that neat gizmo Web service is not a virus or is participating in software espionage or terrorism? Here in New Zealand we may scoff at such thoughts, but in the United States these are very real concerns.
The notion of a public directory of Web services (UDDI) from which one will look up services and then enter into commercial agreements with the providers of those services is short-sighted. It is not going to happen for all but the most trivial of applications. So will Web services gain traction, and if so where?
In the first instance Web services will find a home as an integration technology behind the firewall, integrating systems within an organisation where everything can be managed, monitored and controlled. That is currently where the significant action is with Web services today, not in B2B trading scenarios, despite the hype.
Despite my concerns over the limitations of Web services I believe that it will become a useful and potentially dominant means of low-level application integration, just don’t bet the farm yet! Bill Gates recently said essentially the same thing when he said that Web services would not happen overnight and that it will be a number of years before the model matures.
So what should you do today? Experiment in your own shop with Web services as an internal integration tool. Pilot it to learn what it is good for and what it is not, and stop listening to the hype. You will then know more than the vendors promising to shift your paradigms one more time.
Join the CIO New Zealand group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.