HomeDigital EditionSys-Con RadioSearch Web Services Cd
B2B Beginning WS Business Process Management Case Studies Content Management Distributing Computing e-Business Electronic Data Interchange Enterprise Industry Insight Integration Interviews Java & Web Services .NET Portal Product Reviews Scalability & Performance Security SOAP Source Code UDDI Wireless WS Standards WS Tips & Techniques WSDL WS Editorials XML

Web services offer a widely-accepted standardized frame-work for objects to discover and interact with each other using ubiquitous technologies: XML over HTTP. This article is about bridging two "divides" in discussions of Web services in the press and newsgroups. The first divide is one of perception: ubiquitous services offer radically new ways of thinking about distributed systems, whereas much of the discussion today is about limited incremental steps from today's Web-page technology. The second divide is economic and social: some companies have the resources and the desire to adopt Web services rapidly while others do not. This article explores solutions to cross both divides.

Web Services: Radical Technologies or Incremental Steps?
The initial adoption of a new technology is often incremental. The first cars looked like horse-drawn buggies. The massive impact of a technology is not felt until later.

Web services are radical disruptive technologies. But, just as with the automobile, the initial discourse about Web services is about incremental steps.

First, let me explain why the collection of Web services is a radical technology. Then, I'll discuss ways to harness the technology.

Distributed systems based on message passing or remote procedure calls have been discussed for decades, as have directories that allow objects to find other objects. The theoretical foundation for Web services was established years ago. So, why is the technology radical?

First, Web services are based on ubiquitous technologies: XML and HTTP. Second, major technology companies such as IBM and Microsoft have taken the lead in defining the standards and in developing tools for these standards. The combination of widely-used technologies and intensive support from leading technology companies will result in the rapid spread of Web services standards.

Passive Web Services vs Active Web Services
The most popular examples of Web services showcase passive services. A passive service responds to a Web service request. For example, a currency trading service responds with the dollar-to-yen conversion ratio to a request that specifies dollars and yens. Likewise, a weather service responds with the temperature in Barcelona when a request is made that specifies Barcelona.

Active services offer additional power. They are proactive, whereas passive services are reactive. Listeners register with an active service and the active service invokes a listener with information for which the listener subscribes. Message-queuing systems, such as IBM's MQ Series and Tibco's TIB, demonstrate the value of the publish/subscribe model. On a different scale, the JavaBeans model also showcases the advantages of listeners subscribing for events. The service concept in general and Web services in particular offer an opportunity for extending the publish/subscribe model to a much more powerful level.

Today, many examples of Web services demonstrate simple fine-grain services such as getting the temperature in a city. These Web services are machine-to-machine analogs of human-to-machine applications developed over the last five years. A Web site offering temperature inform-ation in HTML pages now offers the same information as a Web service.

Web services can offer more value by providing coarse-grain complex services that are composed of many fine-grain components. Certainly, return-ing the list of movies playing in a town is a useful service, but an even more valuable service is returning the number of integrated circuit chips of a specified type that can be delivered to a specified factory from suppliers around the world. The latter service is a compos-ition of smaller services that determine how many chips each supplier can deliver and by what date, and then integrate the information into a value-added service.

Coupling Active Web Services
Most business scenarios require multiple events that occur in parallel before a business response is necessitated. A supply chain Web service may reveal the following: One application reveals that product demand is skyrocketing. A typical response would be to issue additional production requests to meet the increased demand. However, an inventory management application may indicate an overabundance of product in the channel and increased production would be unnecessary. Either event detected in isolation may not trigger a response, but if aggregated will warrant action - slow down production or face dumping inventory at the end of the quarter.

Developing an active Web service to monitor the extended enterprise for composite events, aggregate and analyze these events, then actuate applications in response, raises the value of Web services as well as the competitiveness of the enterprise.

Command and Control Applications Using Web Services
Web services offer an opportunity to think about distributed systems, e-business, and collaboration in a different way: command and control mechanisms for the enterprise executive.

The military has used command and control systems for decades. The outcome of wars depends, in part, on the efficacy of C3I (command, control, communications, and intelligence) systems. An Air Force general coined the term "The Warfighter's Infosphere" to mean the command and control system that gives the fighter the information and tools needed, instant by instant. A fighter plane's cockpit is an example of a pilot's infosphere. With today's accelerating pace of business, executives need custom-built command and control systems to monitor and respond to opportunities and threats.

A traditional command and control system consists of three parts: sensors, information fusion and decision support, and actuators. Sensor networks acquire information. Information streams from many sensors are aggregated and decision-support tools are run using the aggregated information. The decisions are fed to actuators that respond to the situation. Radar and sonar are examples of sensors. Computers, databases, and tools for optimizing deployment of military forces are examples of information fusion and decision support. Missiles fired in response to decisions are examples of actuators.

Sensing, fusing, and actuating response to information are equally meaningful to business. Sensors acquire information from Web services, Web-based applications that offer HTML pages, FTP sites, enterprise applications such as supply chain, customer resource management applications, and e-mail. Information fusion and decision-support tools determine whether critical events have occurred and what is the best response to these events. Actuators are interactions with people and applications. For example, the sensor network may show that a supplier will delay shipping a part to a factory. The information fusion and decision-support tools determine whether this delay is a costly disruption of the supply chain and how to respond to the disruption in an optimal fashion. The actuation may be a bid or purchase of an alternative part in an online auction.

Sensing and actuation functions are greatly simplified by widespread adoption of Web services. We can build command and control systems for businesses more easily now because we can build toolkits for developing sensor networks and e-business actuators. A systematic study of command and control systems, coupled with a comprehensive framework and tool set for building them, will produce valuable returns for e-business.

Command and Control vs Traditional Distributed Computing
The lowest layers of the distributed computing technology stack deal with sending bits on a wire, higher layers deal with sending messages, even higher layers deal with sequences of back-and-forth messages between two parties negotiating a transaction, and command and control applications lie on top of the stack.

A command and control view of an enterprise and a military operation are similar. Just as the commander-in-chief, and commanders of naval fleets, aircraft carriers, and individual aircraft have their own command and control systems, so too do the chief executive officer, general managers of divisions, and sales offices have their own systems. The challenge is to orchestrate multiple units in different theaters so as to achieve the overall goal. This challenge is different from the ones discussed in the context of Web services such as how to make services that quote currency conversion ratios or services that accept bids at auctions. A command and control system is, however, based on sensors and actuators, and obtaining a currency conversion ratio is an example of a sensing, and making a bid at auctions is an example of actuating. We can now build frameworks for command and control systems that run enterprises because Web services take care of standardization of protocols lower in the stack.

Jump-starting the Web Services Community
When the telephone was invented, it was ushered in with huge fanfare by the technological leaders of the era. At the time, the rest of the world was using telegraph services to communicate. The result was a slower adoption rate of the telephone. The masses needed to be convinced that it was a viable solution worth their attention and investment. A technology gap resulted: on one side resided millions of telegraph users and on the other resided the first telephone users. If the services offered by the telegraph could be extended to comply with the technology requirements of the telephone, the community of telephone users would have grown drastically.

A parallel can be drawn with Web services. Both the leading technology minds and the media are praising its arrival. Yet, until Web services are accepted by the rest of the business world, its adoption rate will be less than what is needed to grow the Web services community. However, if the tens of millions of Web applications and HTML documents can be exposed as Web services, the rapid adoption of Web services by the masses, and the subsequent population of a Web services community, will be ensured.

Leading-edge companies will introduce meaningful Web services applications in the next few years. Major technology companies, including IBM and Microsoft, offer Web services toolkits today. However, many companies will wait until they see a compelling business need to develop new Web services or retrofit their existing Web-based applications as Web services. This is how the Web services divide will take shape unless steps are taken today to bridge the gap. Treating the human-to-machine interaction process as a machine-to-machine Web service is one way to populate the Web services community.

A retail exchange has thousands of suppliers participating from around the globe. A garment manufacturer in Thailand has a Web site featuring the quantity, availability, and price of his wares. Yet he may be unwilling to invest additional resources to convert his Web site to a Web service. The problem appears minor: the Web site was built for human-to-machine interaction, and Web services require that the site be extended for machine-to-machine interactions using Web services standards. But the problem is magnified when multiplied by the tens of millions of Web sites in existence.

One solution is to extract information non-invasively from Web sites and other document repositories by automating the customary steps needed to interact with these sites. This is not standard screen scraping, rather, it is an approach to locate granular pieces of information from within unstructured pages and payloads of documents.

Most businesses have some domain of discourse. For example, denim suppliers talk about color and weave. Different denim suppliers use different terminology, but they all deal with the same domain. Semantic-based systems can use knowledge of particular domains to understand the information within documents that deal with that domain, and extract information accordingly. Semantic-based systems are less brittle than standard screen-scraping, syntax-based systems.

The key business advantage of these systems is that they obtain information non-invasively. The retail exchange in our example extracts information from suppliers and customer Web sites. Suppliers and customers don't need to do anything other than make passwords available to the retail exchange.

Applying this concept to our example, the retail exchange can offer value-added Web services to its members that non-invasively aggregate information from all suppliers and customers. The retail exchange has "Web service-enabled" all its suppliers and customers, without requiring them to do anything.

IT teams should begin thinking of developing Web services as part of a larger command and control system that resides on the desktops of its executives: an active Web service that senses actionable information, fuses and analyzes its impact, and actuates an orchestration of applications in response.

Bridging the Web services divide is a priority for IT departments. One solution that will help jump-start the adoption of Web services is to non-invasively "Web service-enable" existing applications, without requiring the application providers to do anything.

Author Bio:
Mani Chandy, Ph.D., is chief scientist and cofounder of iSpheres Corporation (www.ispheres.com), a pioneer of meta application frameworks which enable companies to manage business in real-time. A renowned authority on distributed computing, Dr. Chandy is Simon Ramo professor of computer science at the California Institute of Technology, and a member of the National Academy of Engineering. [email protected]

Java and Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. SYS-CON Publications, Inc. is independent of Sun Microsystems, Inc.