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.