Web services? No thanks
Web services are the key to the highly distributed future IT infrastructure we have all been expecting, but their effectiveness could be extremely limited, says Robin Bloor.
It seems that everybody in the IT industry is talking about web services. This is the technology that is going to save us all from our proprietary history.
The market would have us believe that we all have to know the ins and outs of Simple Object Access Protocol, Web Services Description Language (WSDL) and Universal Description, Discovery and Integration (UDDI) and, by now, we should all be building integrated businesses and sharing information with partners and external customers.
The idea is fantastic but is it really practical to invest so much time and effort in an area that is unlikely to be as useful as people think?
Why do we think that web services will be so incredibly useful? It's because we have all been sold a big vision of a highly distributed IT infrastructure filled with loosely coupled application components.
We are expecting to be able to share functionality and exchange information with all who need it, wherever in the world they may be.
Web services were devised at a time when the full effects of the dotcom debacle had not been felt. There was a supportable view that online markets and e-commerce would be key parts of many business models.
Today, we all know that we can't see a time when our organisations will want to build such highly distributed solutions, but the principle is very appealing.
A similar principle was just as appealing back in the early 1990s. Distributed objects were going to achieve something very similar. We didn't do it back then and we're not going to do it now.
If it is not the distributed model that is driving web services forward then we need to look for something else. The key driver right now appears to be the fact that web services technology supports the notion of integrated business.
When you look at all of the major surveys of IT spending, business integration is invariably at the top. Suddenly the big vision of web services has been scaled down to match the availability of budget.
From a business integration standpoint the web services story does look quite good. There is an opportunity to build new components and to expose their functionality to the rest of the business.
What is more, existing functions can be wrapped up in web services code to make legacy systems available to a wider audience.
That functionality then becomes the single consistent method throughout the whole organisation. Re-use is made easy through the use of WSDL for developers and UDDI registries that allow the services to be located.
However, is there any reason to go through the pain of creating web services if the business already has a working solution?
There has always been a problem for software vendors that ask businesses to dismantle an existing solution and to rebuild it using a new set of interfaces. Strangely enough the costs involved seem a little difficult to justify, so the acceptance of such ideas is never quite what the vendors expect.
This is even less likely if there is widespread belief that the new interfaces - no matter how interoperable they are - will actually bring about a reduction in performance levels.
This is the real barrier to the success of web services. For years business integration has been based on the delivery of proprietary messages. This has been possible because anything that needs access to data or functions has done it in a tightly coupled way. There has been no need for standards.
Proprietary solutions are usually more efficient. As soon as you replace these with standards-based approaches, you introduce the necessary overhead of caring what others may need.
In the case of web services this means wrapping information up in pages and pages of XML. This results in slower initial processing as the information is wrapped up, more network traffic as longer messages are passed, and increased processing time to unravel the message again.
Nobody in their right mind will want to deliberately increase the resource demands from their applications. There has to be a good reason to do it.
That can be justified only where information is going to be shared with other standards-compliant applications.
It doesn't take a rocket scientist to work out that, internally, there is a problem with web services. There is little to justify the effort and overheads associated with building or modifying applications to work in this way.
The only area where web services will be really useful is where services are to be exposed to external partners or other third parties.
The level of interest in web services technology that each business has should be related to the percentage of its business that it carries out - or would like to carry out - with external organisations.
So most of us can be content to take an academic view without much fear of actually having to do any of it.