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."