Six Things Web Services Are Not

As a technologist I'm always intrigued when the market begins to go crazy over a new buzz phrase - and recently I'm seeing it happening with Web services. Every software company, big and small, claims to be into Web services leading folks to wonder what Web services really are. Although there is certainly some new technology here ( mainly directed towards standardization - you may have heard about Simple Object Access Protocol or SOAP, Web Services Definition Language or WSDL, and Universal Description, Discovery and Integration or UDDI) Web services are largely a convenience wrapper around existing technologies like HTTP, SMTP, and XML.

A Web service is a way to expose some business functionality over the Internet using the SOAP protocol (A Busy Developer's Guide To SOAP). It is portable, interoperable and not tied to any one vendor and this is precisely why it is useful.

Technically speaking, here's how a Web service works. A client wanting to call a function formats a request with SOAP XML encoding, and sends it to the server over any mutually agreeable communication protocol (typically HTTP, but SMTP is possible). The server runs some sort of a listener that accepts the incoming SOAP calls, reads the information from the XML SOAP packets, and maps them to business logic processing "application" software on the server. This application layer on the server processes the request and returns output to the listener, which formats the output into a response packet in the SOAP XML encoding and returns it to the client. A separate XML file contains a description of the services provided by the server in an encoding format called SDL (Service Descriptor Language), analogous to a type library in COM or an IDL file in CORBA.

While most people are in alignment regarding the technology, there continues to be confusion in the description of what Web services are really capable of, and what their attributes are. Rather than describe each element exhaustively, let me take a cut at examining what Web services are NOT.

1. Web services are NOT just consumer focused Internet toy applications that allow you to get the latest stock quote from an airplane, or weather updates from your shower. More significantly, they are an enabler of efficient enterprise-to-enterprise interaction. They are not a fundamentally new business concept, just a technology that permits an old business concept to work better. Pairs or groups of companies and organizations that have an existing business relationship will now find it easier to use well-defined Web services to interact, exchange data selectively and thereby automate business processes that span across these enterprise groups.

Rather than having a unique interface for dealing separately with each inter-company interaction, Web services provide a way for enforcing some uniformity in encapsulating these interactions. For example, a vendor of automobile parts can easily provide a programmatic interface to its suppliers for inventory inspection and replenishment. In this case, the parts vendor can call the Web service as part of some program, and use the information that is returned to guide and conduct future actions i.e., if some parts are short, automatically order a replenishment.

2. Web services are NOT independent of Web applications. Web applications form the technology foundation and Web services provide the glue for interactions and integration. Thinking about Web services as distinct from Web applications is a fallacy that vendors and customers can fall into if they are not careful. Take the auto parts example above. The right way to be thinking about creating this application is to begin by figuring out what the enterprise inventory management process looks like, how it can be automated using a Web application, where interactions with vendors fit in, and how they can be enabled using Web services.

A superior application development and deployment platform is one that enables you to automate the inventory management process and seamlessly connects the external interactions using Web services without having to do anything different. An elegant way to do this is by allowing applications to be configured using modules that are Web services ready i.e., can exchange data back and forth in SOAP/XML. Technically, here's how such a modular approach can work (see for example the SiteWand platform from Instantis):

Each module of the application could be a request handler for a single type of request, i.e., the business logic for handling that request. The complete application then consists of multiple such request handlers working in concert sharing sessions and or database state. Some of the request handlers in the application (e.g., those receiving human input) interact with a browser based UI for the application (handling HTTP posts/gets containing HTML pages). Other request handlers serve as the integration layer to other programs. The integration layer processes XML requests from the communications link, and passes them onto the business logic layer, which processes the logic while accessing the data layer as necessary. The response then goes back to the integration layer, into XML and over the communication link back to the client of the Web service.

3. Web services are NOT solely externally focused. A significant number of Web service applications will be focused on enabling applications within the enterprise to communicate with each other. In fact, Web services are ideally suited for this task. They provide a mechanism for intercommunication between systems in a platform, applications and network protocol in a neutral manner. Since Web services are typically implemented over HTTP (the standard Internet Web protocol) it doesn't matter what systems are used by the transmitter and the receiver.

Before Web services, communication between two applications involved using a closely coupled mechanism where one program called the other through an API (often a client stub of a RPC - remote procedure call - implemented using CORBA or DCOM). When using Web services for application integration, as long as the data elements and document definitions don't change, old and new applications can work together without changing anything in the communication layer. Communicating at the API level, on the other hand, would mean having to upgrade an application and re-deploy it (along with new versions of all its clients). In a distributed network with many nodes, trying to make all these changes simultaneously is impractical. Hence using Web services for application integration is analogous to the Web itself where the browser and server are not tightly coupled.

Existing (legacy) business logic can be accessed (and incorporated) into new applications by wrapping them with Web service interfaces. For example, consider implementing the business logic for a "user login" step in a new application. The logic may have to consult a central authentication database in LDAP. This can be done by wrapping the LDAP database with a Web service interface and accessing this interface as part of the login processing.