What Web Services Are NOT (2/4) - exploring XML

Living documents with XML events

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 (if you've never "seen" a Web service, or for an example of how easy it is to set one up, see the "gallery" at www.instantis.com).

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.

   The following figure illustrates this architecture for constructing Web services:

   

   An inferior approach to solving the problem above would make you believe that the Web services (e.g., vendor interactions in the example above) are the key components, and you need to re-architect your application (e.g., inventory management) to accommodate these Web services.

On to internal Web services and the myth of one XML standard.

Produced by Michael Claßen

URL: https://www.webreference.com/xml/column50/2.html
Created: Feb 16, 2002
Revised: Feb 16, 2002