Web Services: Time yet?

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.