RealTime IT News

The Case for Web Services

The Internet has transformed the information age. The Internet Protocol, along with a worldwide communications infrastructure, delivers data communications everywhere at low cost. Today, the bulk of Internet traffic is end-user related, e.g., e-mail and Web browsing. These services will continue to dominate; but in the coming years, we will see more computer-to-computer communications. Information found on the Web is primarily targeted for human consumption; machines have trouble digesting all those font tags and style sheets.

Greater automation of business processes will lead to improved overall efficiencies. In order to automate many of these processes, organizations must exchange information with their suppliers, financial institutions, and service providers. The challenge in realizing this information exchange lies in developing standards and protocols that everyone can agree on and can be efficiently implemented by a wide range of organizations. Such standards must be open, or there is little chance of widespread adoption. The cost of implementation must be minimal, as the average business has only four employees. The implementations should rely on existing infrastructures and tolerate limitations and faults in the network. The solution must also be flexible in order to accommodate the diversity of businesses.

Web services provide a simple mechanism for organizations to discover each other and exchange information.

Let's consider a simple supply chain example. A customer orders a product from a distributor, let's say a laptop with extra memory. It's possible that the supply of memory might run out before the laptops. If this happens, the distributor must contact the memory supplier, determine the lead time, and order the product. Depending on availability, the price of the memory might change, which affects the price of the laptop. The customer wants to know when his laptop will arrive and the total cost. He might even want to be notified on a wireless device like a cell phone, pager, or PDA. The laptop distributor can contact several memory suppliers to find the lowest price and least lead time. This quote from memory suppliers is one example of a typical service that can be automated.

Another service might route a notification message to the customer regardless of his wireless carrier. It sounds like an obvious thing to do, but a large number of businesses today still do things over the phone. There are lots of people involved. This increases cost, time, and it's unlikely to yield the best service at the best price.

Possible Solutions

There are a number of technologies that can be used to permit organizations to interact over the Internet. There already exist several off the shelf solutions that perform common B2B operations such as placing orders from suppliers and performing financial transactions. These solutions can be very effective for certain businesses; but like most off the shelf solutions, their flexibility is limited. Businesses must often adapt their process to the software instead of the other way around. Other problems include high cost and the challenges associated with integrating large software with an existing enterprise. In many cases, the software uses proprietary protocols that make it difficult to integrate with other enterprises using different software.

Distributed computing using CORBA or RMI is another possibility. These technologies are robust and efficient but don't work well over large, diverse wide area networks. CORBA and RMI are object-based and tend to be too tightly coupled for many applications. In order to make use of CORBA or RMI, you must fully understand all of the objects that are sent back and forth. It's hard to get people to agree on even the simplest objects. More importantly, these protocols are difficult to implement through firewalls and don't tolerate network faults very well. These are some of the reasons why CORBA is not such a hot technology for wide area networks, but it does work well in a LAN environment where the network is more predictable. CORBA and RMI are most effective within a single enterprise and are often used with clustered application servers, such as EJB containers. What the application servers need is a simple front end to the outside world.

It is widely accepted that XML is the preferred means of data exchange. XML documents are like objects in a way, but they tend to be easier to work with. XML documents are not the most efficient in terms of data transmission, but they are easy to create, validate, and parse. More importantly, XML documents can be easily translated into other XML documents in order to manage the diversity of vocabularies among businesses. For example, one business might charge expenses to an account where another business might call it a cost center. Nonstandard vocabularies are one of the roadblocks to seamless information exchange. XML translation using XSLT can solve this problem without too much trouble.

Given XML documents, how can they be exchanged? A standard that is gaining favor is the Simple Object Access Protocol (SOAP). SOAP is a protocol that works over HTTP, so it can leverage existing Web servers and work through firewalls. Strong security can be added through HTTPS. Since SOAP works over HTTP, it is essentially stateless. A client connects to a server, issues a request, and receives an XML document in return. Unlike CORBA or RMI, SOAP connections are not persistent. If there is a glitch in the network, the client simply reconnects and issues the request again. CORBA and RMI implementations must obtain remote references ahead of time; this makes it difficult to reconnect. What usually happens is that someone eventually finds out things aren't working and restarts a server or two. That's the best option if you want to run a reliable 24/7 operation.

SOAP solves many of the communication problems, but doesn't support any kind of metadata or description of services that are available from a given server. This is where the Web Services Description Language (WSDL) steps in. WSDL is essentially an interface definition in XML. A WSDL document specifies the operations that are available from a vendor along with other details, such as port numbers, data types, and protocols to be used. The operations are essentially method calls in the CORBA/RMI world. Data types can be defined in the XML Schemas specification (XSD), but it is extensible and allows other type definitions. Currently, a number of protocols can be used for data exchange. These include SOAP, HTTP, or MIME, but others can be specified.

Once we have a protocol and an interface describing a service, the next step is registration and discovery. This is supplied by Universal Description Discovery and Integration (UDDI). This is an open framework that permits businesses to discover each other and share information in a global registry. Businesses can publish their Web services in a UDDI registry so that others can discover these services and conduct business. The information provided in a UDDI registry consists of three components: white pages, which include address and contact information; yellow pages, which contain standard industrial categories; and green pages, the technical information about services that are exposed by the business. Green pages include references to specifications for Web services, as well as support for other discovery mechanisms. UDDI alone is a powerful electronic tool that can connect all kinds of businesses all over the world.

Web services provide a simple mechanism for organizations to discover each other and exchange information. Essentially that is what business is all about. If industry momentum continues as it has, it is likely that Web services will make low-cost, widespread B2B a reality in the near future.

About the Author

Madhu Siddalingaiah is a consultant with an interest in emerging technologies, such as Java. He holds a physics degree from the University of Maryland. He is the author of Java How-To and co-author of Java API for Dummies Quick Reference. Before Java, he specialized in satellite instrumentation, communications receivers, and 3D graphics. When Madhu is not working, he may be found flying helicopters and playing drums, but not at the same time.