In fear of Web services

The hype tells us that Web services are the future, but so far few user companies have adopted the technology. Are you right to...

The hype tells us that Web services are the future, but so far few user companies have adopted the technology. Are you right to be cautious? Sally Whittle investigates.

In a world of end-to-end, real-time, turnkey solutions, Web services make sense. The idea that applications can communicate dynamically over the Internet without the need for costly integration, allowing companies to create endless new services for customers and partners, is very appealing.

Even better, Web services are based on open Internet standards, meaning that businesses can build and buy products to support their Web services free from the spectre of supplier lock-in. Using Windows 2000 Datacenter, some custom code and a Sun server, for example, a car rental firm could link into an airline reservation system, or a hospital could integrate its drug ordering and insurance billing systems. At least, that is the theory.

In reality, Web services are unlikely to be anything more than a slight improvement on EDI (Electronic Data Interchange) and EAI (enterprise application integration) for the next couple of years. Studies conducted by Forrester Research show that 33% of companies have no plans to implement Web services. The analyst firm estimates that just 5% of businesses are currently using the technology, and those that are using it are doing so in a fairly limited way. "Web services are probably more commonly used than people think, but it is definitely a minority and restricted to internal non-critical applications," says Charles Homs, one of its senior analysts.

Because the market is so immature, even the analysts are still learning the pitfalls. "It is extremely difficult to tell clients with any certainty how to make sure they are safe," says Homs. For example, the current generation of Web services could put enterprises at risk of unsolicited messages, denial of service attacks, or a domino chain of services where you no longer know what company you are doing business with.

Unsurprisingly, enterprises are waiting until they can buy the components of Web services from trusted suppliers. Mike Gilpin, a research director at Giga Information Group, says, "Most Web services around today were built using free tools downloaded from the Internet. That is fine for those hardcore developers who believe high-level abstraction is for wimps, but most enterprises see it as a bleeding-edge technology."'

There are three main standards at the heart of Web services: Simple Object Access Protocol (Soap); Web Services Description Language (WSDL); and Universal Description, Discovery and Integration (UDDI). UDDI is a virtual directory, listing all the services available to a system, while WSDL tells "requesters" how information is listed and where to find it within the directory. Soap provides a standardised way of sending XML messages and their headers from one application to another.

"But the reality is that, in terms of UDDI especially, the technology isn't there," says Mark Pritchard, a senior architect at software supplier BEA Systems. For this reason, most companies are focusing on XML and Soap when building Web services, which are then used internally or in a closed system between themselves and a trusted partner.

Even then, today's Web services are fairly limited, says Kevin Malone, an IT consultant at IBM. "The standards are fine, so long as you don't want to do too much handshaking," he says. "Once you get into complex ifs and buts, the standards aren't yet settled."

Despite the immaturity of the technology, some companies are forging ahead with Web services. Royal Dutch Shell, for example, uses Web services to exchange regulatory information with the Department of Trade & Industry, and investment bank Merrill Lynch uses them to alert clients when new research is published. Early adopters report quicker time to market thanks to simplified integration and lower development costs, with less need for highly complex code.

However, most companies have been restricting Web services to internal use, or within a closed collaboration with a single, trusted partner. "The tools required to make services robust - authentication, transaction processing, filtering - are not available, so companies have to either build their own or restrict Web services to services that do not require security," says Gilpin. Currently, Web services make most sense internally, where they can be used to tie together disparate functions and integrate business processes, he adds.

Those tools will become available over the next 12 months, says Homs. "Unsurprisingly, all of the vendors are trying to position themselves as Web services specialists," he says. "The platform vendors are building in development tools, and the application vendors are rewriting their products to support the standards."

Gilpin identifies the main suppliers in the Web services market as Microsoft, IBM and BEA, followed by Oracle and Sun, in that order. These companies are providing products in three key areas: developer tools, integration tools and application servers.

Microsoft has the early lead, but Gilpin believes it could yet be derailed by its poor record on security - often seen as the biggest potential pitfall of Web services. Microsoft chairman Bill Gates has bet his business on Web services with the company's .net strategy, which spans Office, Windows 2000 Datacenter and everything in between, and he hopes to persuade application developers to use Visual Studio .net to create Web services in Windows' image.

BEA is heading a posse of suppliers that support an alternative environment based on the Java programming language. Together with IBM, Oracle and Sun, BEA Systems' Weblogic application server uses J2EE (Java 2 Enterprise Edition) technology rather than .net. These companies are also backing an alternative to Microsoft's Passport directory - the secure digital certificate technology that enables people to access user-specific Web services - through the Liberty Alliance lobby group.

BEA's Weblogic 7.0 is expected to ship in the next three months and will include Web Services Workshop, an add-on that will help companies develop new Web services in an easy-to-use visual environment.

IBM's long-term strategy, like Microsoft's, appears to be centred on Web services. "Tivoli can manage Web services, Lotus can handle Soap messages, and DB2 can issue Web service calls - any IBM product is relevant to Web services," says Malone. However, the hub of IBM's strategy is the Websphere application server, which implements Web service standards and offers businesses the security, scalability and reliability they require, says Malone.

Sun Microsystems is a relative latecomer to the Web services market, and is unlikely to be a leader, says Gilpin. However, the company's decision to rebrand the iPlanet family of products under the Sun One Web services banner is an indication of its commitment, claims Adrian Keward, Sun One pre-sales manager. "We can offer an end-to-end Web services solution," he says. "The Sun One Portal Server provides the front end; we have the Sun One directory for listing and authentication; and a Sun One Application Server for the J2EE functionality. They all support Soap messaging, and you can add a UDDI extension to the directory server."

The success or failure of these products hinges on the suppliers' ability to stick to the standards agreed by the Web Services Interoperability (WSI) Forum. "We take interoperability very seriously," says Pritchard. "You can use all of BEA's stuff with .net."

So far, the signs are good, but don't expect it to last forever. "The standards issue is not as doomed as some curmudgeons would have it, but there is potential for divergence," says Gilpin.

While the WSI Forum could ensure interoperability for low-level Web services, Gilpin believes it is inevitable that suppliers will add on proprietary extensions in time. "In a couple of years, vendors will be tempting you with features that go beyond the standards, just as they have in the portal sector," he says.

Although the market has failed to live up to the early hype, there is still a lot to be said for Web services. "It is definitely not the revolution that some vendors said. But it is an evolution that could save companies tens or hundreds of thousands of pounds in integration and development costs, and help them find new ways of doing business with partners," says Malone. "Whatever you believe about the future of Web services, that is a given."

Case study; Levelseas
LevelSeas is a UK-based service provider for the shipping industry. Founded in April 2000 by companies including Shell and BP, LevelSeas offers an online chartering marketplace, shipping analytics and a custom voyage management system.

The company has already rolled out some simple Web services, including a contact synchronisation tool for customers using the chartering exchange. "The e-mail platforms used by customers vary widely, and they want to be able to use that information on our site securely and quickly," explains Simon Harris, LevelSeas' head of development.

When a customer logs in to the exchange they can opt to synchronise their Outlook, Notes or other client software's contacts and scheduling information with the exchange. This ensures that errors are reduced and that customers have access to the most up-to-date availability information. The service runs on a BEA Weblogic server, while the underlying technology uses Microsoft Soap 2.0 to send XML messages and mediates with back-end Enterprise Javabeans to fulfil client requests.

The service took less than two months to develop and deploy, and the cost was minimal, says Harris. "It does save time, and it saves a small amount of money, but we were more interested in whether we could do it, and if it would work," he says.

LevelSeas is now developing and testing a series of more complex Web services, including a voyage management Web service, which will let cargo ships and customers share data automatically. "The idea is that people on the vessel will enter information into a client on the ship, and send an SMTP message along with the other e-mail," says Harris. "The message is then delivered automatically into the client's back-end system as a Soap message over SMTP."

Read more on Web software