If you want to get to the bottom of what Web services really are, you have got to put all the acronyms and protocols surrounding them to one side for a moment.
Mike Lucas, technology director at Compuware, says some of the confusion about Web services arises because people get too bogged down with the enabling technologies. "What is more important is the concept," he says.
"It might help to think of Web services in terms of your electricity supply. You don't generate your own electricity, you just plug in there. The electricity is delivered in agreed standard units and you have a meter telling you how much is being consumed."
He says Web services will mean that companies will no longer have to build applications in-house but will instead be able to hook into applications already out there on the Web. "Expect to see new companies providing Web services sprouting up," Lucas predicts.
Web services are generally regarded as the next stage in the evolution of the Internet. Beyond static Web pages and transactional Web sites, Web services are about applications talking to other applications over the Internet via XML-based middleware standards.
Earlier approaches to integration included electronic data interchange and electronic banking initiatives, but these were expensive as participants paid carrier transmission fees.
With the advent of ubiquitous, reliable, secure Internet connections and a standard communication system in Extensible Markup Language (XML), companies created software to establish electronic marketplaces. These started out as independent companies but they have turned into industry-sponsored consortia, along the lines of Covisint, which was formed by major players in the car making industry.
Jason Vokes, European manager for software house Borland, says that while these marketplaces have been used successfully for auctions and other sales transactions, many more business processes can be automated between companies. The concept of the Web service is to make any business process available for business partners to use.
Over the past few years work has been under way to create a well-defined framework, known as EBXML, for encoding information. The interface to a Web service can be defined with the new Web services description language, while the Simple Object Access Protocol (Soap) defines a mechanism for the transmission of information.
"Not only will it enable you to integrate applications within a company, you will be able to connect with any application on any system in the world as XML and Soap are platform-independent," says Vokes.
He says organisations will be able to look up these applications using UDDI (Universal Description, Discovery and Integration). This is an XML-based registry that businesses can use to list their names, products, locations and the Web services they offer on the Internet.
"An early example of Web services are companies that have integrated with a carrier's system, such as Federal Express or DHL," Vokes says. "If someone rings their call centre and wants to know the status of a widget that has been sent out using Fedex, the call centre operative can add value by going into the Fedex systems and finding where the widget is."
Kevin Malone, technical strategist at IBM, thinks that most of the development in Web services will be in the business-to-business arena. "Areas like the insurance industry where there is a lot of to-ing and fro-ing of data will be able to make use of Web services," he says. "You can see retailers adopting them, for example, where a customer purchases an item online but wants to choose from a selection of delivery companies or a range of payment systems."
Other possibilities come from the likes of online auction sites eBay or QXL which are talking about making their core auction processes available for other companies to use.
However, there are several issues that must be ironed out before we reach the open interchange of application data that we have been promised. These include:
- Payment for Web services - there are a variety of micro-payment, subscription, and per usage models and time will tell which are adopted
- The security implications - firms will be opening up their applications on to the Web
- Integration between internal and external systems - companies which run or use Web services will need to plan and test their networks to ensure they have the sufficient capacity.
Lucas talks about the need for stricter certification of services. While Web service applications are listed in UDDI directories, he asks whether providers of Web services can guarantee quality of service within agreed boundaries. Service level agreements are on Malone's agenda too, particularly for longer-running transactions. Bola Rotibi, an analyst at Ovum, fears that Web services may go the way of previous attempts to create open standards. "The standards landscape is littered with specifications that have too many overlapping functions. Web services are in danger of becoming fragmented before they are given a chance to work," she says.
Suppliers must work together to grow the market, says Rotibi, and online marketplaces and trusted service providers will have a major role to play.
She says the first stage of Web services development will happen inside companies. "Organisations will concentrate on getting to grips with Web services technology and apply it to simple internal application development," Rotibi explains. "It will be some time and require a more robust framework before users are prepared to use Web services for integration with external applications in the way that suppliers are hyping about."
Malone concurs, and sets out a slow step progression on how IT departments can dip a toe into the Web services water. "When a new in-house application comes online, set up a UDDI directory for it," he says. "Set up clear interfaces and then expand by extending them to well-established partners. Eventually you will feel ready to publish the service on the Internet."
This was first published in March 2002