While
the core of the Web services set of protocols has been agreed upon,
many supporting protocols are still in the shop. Is there value in
implementing Web services right now, and how is it best to implement
them?

It slices, it dices, it cleans your
kitchen floor. There are few business technologies attracting the same
kind of hype as Web services. According to its proponents, Web services
promise to deliver a solution to a problem that costs business billions
of dollars every year – how to get all the business systems to talk to
each other. It promises to be a universal enterprise application and
data integration tool, a lingua franca for modular business
applications. Rather than hand-coded individual interfaces, we now have
a 'universal' interface between business applications.

At its core
are HTTP as the transport, XML as the data container (with various
industry and application-specific schema), the Simple Object Access
Protocol (SOAP) as a tool for remote procedure calls, the Web Service
Description Language (WSDL) as a means by which to publish information
about a service, and Universal Discovery Description and Integration
(UDDI) as a means of indexing and locating services.

In
a Web services implementation, each business application exposes its
functionality through Web services; business processes draw on those
exposed functions to create a working system. With every application
speaking the same language (XML and HTTP), data interchange and
application integration should be a breeze.

Right
now, however, the reality is far from the hype. "The interest in Web
services in Australia is extremely high," says Bruce McCabe of S2
Intelligence, "but in terms of production deployments, there aren't
many companies involved yet. At the beginning of 2003, I found only
about 18 companies [in Australia] that were using Web services in
production. In total, there were certainly less than 50 Web services in
production in Australia. Today I would put the number between 100 and
200."

"You
won't see extensive use of Web services for business to business
ecommerce for 2 to 3 years," he says. "Five years from now, people are
going to wonder what we're talking about, because everybody will be
using Web services as a matter of course. There's a big 'if,' however.
That will only happen if it doesn't go off the rails with standards
battles and whatnot."

What
success Web services have had so far is in behind-the-firewall EDI and
EAI applications. Public implementations of Web services in Australia
have largely been confined to government institutions. The Australian
Bureau of Statistics is the best known user of Web services, and
several other government departments have implemented minor Web
services. Business, however, has been less keen to put itself out
there, and there are very few major implementations of B2B or public
Web services in Australia. "More than half our customers are looking at
behind-the-firewall applications," says Malcolm Groves of Borland.
"People are hesitant to expose their business early on in the
implementation cycle. As with any new technology, people kick the tyres
for a long time."

Building a Web service
Web services
right now are commonly built using an adaptor layer, that sucks
information out of a legacy application and presents it as a Web
service, and can relay Web service requests (such as SOAP function
calls, or XML query language requests) to the application.
Fundamentally, they act as a front-end or wrapper for legacy
applications. Suddenly the functions of a legacy CRM application, for
instance, are exposed and callable using the simple and universal
syntax of SOAP.

What
the standards have not yet adequately addressed are issues of
end-to-end security, management and workflow, transactions and
choreography, scalability, and reliability. As of right now, Web
services only supports transport (HTTP), remote invocation (SOAP) and
directories (WSDL and UDDI). While more standards are being worked on,
many are a long way from completion. Most implementations are
point-to-point, without intermediaries. That's where the middleware
platforms come in.

Tools
like Microsoft BizTalk, IBM WebSphere, and Oracle Application Server
(and the gamut of other middleware platforms) function as important
logic management environments, simplifying or automating the generation
of business process trees and WSDL documents. They can help smooth over
the distinctions between implementations of SOAP (for instance, the
.NET and J2EE approaches are slightly different), and act as an
authoritative source of information on services.

There
are a number of off-the-shelf Web service middleware applications with
adaptors for popular applications. Microsoft's BizTalk server, for
instance, has several hundred adaptors available for various
off-the-shelf applications.

For
custom applications, the difficulty of building a Web services
interface will depend largely on the application for which you are
building it. "In some cases it's surprisingly simple," says Peter
Menadue of Dimension Data. "But if you come to an application that
doesn't expose its data easily, then it can be quite complex."

According
to Avanade's Darrell Ryman, the real challenge is not the development
itself, but the implementation of the business processes. "Writing a
Web Service is the easy part of the equation—understanding the business
implications is the hard part," he says.

It
is also quite clear that developing Web services now and developing Web
services two years from now will be very different. With every major
vendor (including SAP, J.D. Edwards, PeopleSoft, IBM and the like)
planning to integrate Web services into their product cores, the need
for third-party adaptors will dissolve. The Business Process Execution
Language (BPEL) and similar standards will formalise the workflow
processes (should the standards dance between the competing interests
ever be sorted out). The middleware will become less an environment in
which to build and host a Web service wrapper, and more a business
logic management tool.

According
to IBM's Iwan Winoto, Web service middleware will still have its uses.
"There is still a case for using a broker to make sure that one system
acts as the main authority for Web Services. You're still going to need
a way to manage your connections between all these applications."

Why build Web services
The
fundamental question for business is: is it worth implementing right
now? You may need to build an extra tier. You may have to implement
applications-specific front-ends, and invest some serious development
time in building a system that does things that replicates functions
that you already have running. And if you wait, the core applications
will eventually have Web services built in.

According
to McCabe, very few companies are willing to undertake a forklift
upgrade, but are instead planning to use Web services for new projects.
"In my experience, companies aren't replacing their working systems.
They're focusing on new applications and new linkages," he says.

"There
is no value [in implementing Web services] today if what you have works
right now and if it costs very little to maintain," says Menadue. "It
sounds great—but a lot of focus these days is on getting value. You
have to ask: what's the ROI?"

"More
and more things are having XML services baked in," he says. "We have
customers saying, 'let's just over time bleed in Web service-enabled
applications. And then when we need to activate the Web Service
features, the infrastructure will be there.'"

"We
have customers who have evaluated it for behind-the-firewall
applications ad have found it not suitable," says Groves. "There are
things that proprietary solutions can do that the specifications do not
yet support. There are things today that companies need, but Web
Services does not support. That said, the standards are evolving faster
than you've ever seen."

There
are arguments for implementing Web services right now. "Customers
aren't buying into Web services per sé—they're looking to minimise the
cost of ownership and deliver the best solution for their business,"
says Ryman. "I don't know how many customers have a thousand
applications getting the same data from the same source. Rather than
have all this code, Web services allows you to have one re-usable bit
of code. I see a lot of customers using it to define an authoritative
source."

Steve Baty, senior analyst at Red Square
Productions says building Web services right now for
behind-the-firewall applications also prepares companies for future B2B
applications. "Some of our clients have been deploying Web Services for
6-12 months," he says. "What we haven't done is expose those Web
Services externally yet. In the future, when we want to expose them,
all we need to do is switch the function. It's not a stretch to expose
that product data to the Internet."

Who's doing it?
Despite the
hype, you won't find many Australian companies right now who are using
Web services in the field, either for behind-the-firewall applications
or public applications. The government, however, has embraced Web
services, and is already offering a number of Web services to the
public.

The Australian Bureau of Statistics
is using Web services to automate the collection of data from business,
especially retail information. There are also plans to expose ABS
statistical information to Web services, in order to facilitate the
integration of that statistical information in authorized business
applications.

The Australian Taxation Office is using Web service technology for lodgement, business registration, and integration systems.

Western Australia's FuelWatch
uses Web services to gather fuel price information from service
stations and distribute that information to its clients via SMS, the
Web and email.

Smorgon Steel
is an example of a business using Web services to effect EAI and EDI
within the organisation. It has deployed webMethods to integrate
disparate ERP systems between facilities. Previously it had developed
point-to-point interface between each of the ERP systems. Now each
system presents a Web services interface.

Join Discussion

Thank You

By registering you become a member of the CBS Interactive family of sites and you have read and agree to the Terms of Use, Privacy Policy and Video Services Policy. You agree to receive updates, alerts and promotions from CBS and that CBS may share information about you with our marketing partners so that they may contact you by email or otherwise about their products or services.
You will also receive a complimentary subscription to the ZDNet's Tech Update Today and ZDNet Announcement newsletters. You may unsubscribe from these newsletters at any time.