Will Web services actually work?

You've heard the hype, now discover the real-world opportunities and challenges Web services present.

You've heard the hype, now discover the real-world opportunities and challenges Web services present.

On paper Web services will solve all IT interoperabillity problems. Applications, we are told, will conform to certain standards that will allow users to bolt on and log in to systems that previously would have been off limits to them.

Choose your partner
At the heart of this is the Universal Description, Discovery and Integration (UDDI) standard - an initiative designed to build a marketplace for Web services by creating a standard way of listing and describing them in an online registry. Suppliers originally wanted to use UDDI and Web services as a means of finding potential business partners online. These partners would expose elements of their back-end systems as Web services, theoretically enabling new suppliers and customers to simply interface these Web services with their own systems in an instant supply chain scenario.

That is the theory, at least, but some experts feel its unrealistic. "The big issue that I have is this wild world of B2B Web services, partly because of the technical challenges, but also because it misses the point," says Gary Barnett, an analyst with research group Ovum. He feels that whereas Web services seek to automate transactions, business relationships are forged manually.

Web services may be useful to companies that already know each other and want to integrate their training systems, but when it comes to creating the corporate equivalent of online dating services, UDDI will be largely useless because businesses are unlikely to want to do things this way. Deals may be executed online, but they're made in boardrooms and on golf courses.

Design constraints
Even if you find a business partner with whom you want to integrate, Web services will still bring challenges similar to those that have faced distributed systems development teams for years. Mark Collins Cope, technical director at Ratio, a company that sells training courses for object-oriented programming, says that handling communications between components across an amorphous public network like the Internet will place design constraints on developers:

"There are a lot of design issues with distributed software - you don't want masses of information floating across the network," he says. You have to minimise network traffic. I wouldn't want lots of tiny calls going across the network all the time. You want to send big chunks across at once. This is just distributed system design."

Service you can rely on?
Another issue is the lack of service level agreements between Web services. Although Web services are extensible the standard UDDI specification, for example, does not include any information about service level agreements (SLAs). The first thing that any IT team will ask when interfacing with a third party Web service across the Internet is how reliable the component will be. Will it be available 24/7? What will the guaranteed response time be?

All this raises its own questions - if you are dealing with several different components at once across a wide area network, it becomes difficult to maintain the traditional characteristics of a database transaction, for example.

Peter Bell, a business strategist at Microsoft, says that the traditional two-phase commit process used in database middleware to guarantee transactions won't work in such a loosely-coupled architecture. "This is a big science issue at present where people are looking to compensation models as a method of doing transactions. It deals with the issue of long-lived transactions over many sessions between many parties," he explains.

Organisations are looking at protocols to facilitate these "long transactions". The business transaction protocol from the XML interoperability consortium Oasis is one possible solution.

Don't leave the back door open
On top of these concerns, companies using Web services will have to think very seriously about security. Exposing your back-end services to the world at large opens up the possibility of hacking.

This is going to make IT directors understandably nervous, and while it does not negate the concept of Web services altogether, it certainly tempers the jingoistic attitudes of many vendors who do not mention security very much in their marketing literature.

Companies are already embarking on activities to improve Web service security. IBM, Microsoft, and Verisign recently announced a specification for exchanging security information in extensions to Soap-based messages. But this hasn't been ratified as a standard yet, and will not solve all the potential problems, such as denial of service attacks.

Architectural concerns such as these will not kill Web services - there's too much enthusiasm for that - but it will mean that they are mostly implemented on an internal basis in the short to mid-term.

Companies will use them to better integrate their own software components rather than attempting to hook into Web services hosted by third parties.

Clearly for now, the message is not to let vendors wow you with stories about B2B Web services. Instead, stick to using them for internal developments that will deliver real deliverables in the short term. Tackle the fun stuff later when the market has matured.

Read more on Web software