Putting Web Services Standards to Work

Page 2 of 3

Suitable Settings
While the potential benefits of Web Services are clear, the extent to which these benefits are actually realizable depends on both the business sector in which an enterprise operates and its own specific IT environment. "Web Services are not the right approach for high-performance systems, especially real-time system or low-bandwidth networks," Le Hégaret says. "Or for closed environments that don't need to interoperate with the outside world."

David Orchard, technical director at BEA Systems in San Jose, California, agrees that Web Services would not offer much of an improvement in "homogenous environments, such as all-Microsoft, or where the environment is fairly simple." On the other hand, Orchard offers a couple of projects in which BEA has participated as examples of effective Web Services implementation.

In one project, traders from an unnamed "Fortune 500 financial services company" were working on Visual Basic clients with snapshots of market data stored in local databases. "The client apps did not previously have access to the Java/CORBA backbone responsible for real-time transaction processing," he says. "But using Web Services, the company was able to unify the front-office trading applications with the financial transaction backbone. This allowed traders to work on live data, and eliminated maintenance of front-end application business logic."

Orchard also cites the experience of "a government agency" that operates aircraft carriers and battleships, and needed to better integrate intelligence-gathering legacy systems to command-and-control applications. "Web Services made it possible," he says, "to securely integrate legacy applications deployed on different platforms, and thereby reduce 'time-to-target' from hours to minutes."

Barbir, meanwhile, speaks of healthcare as a prime example of a sector in which Web Services can improve workflow. "Web Services," he says, "enables agents on wireless devices that the doctors and nurses can carry around in the hospital to provide immediate access to patient data, and also to access professional opinions of other doctors on-the-fly. Furthermore, patients can have access to some or all parts of their files from their homes. Web Services can also eliminate the need for X-ray film by providing digital versions that can be used for real-time collaboration, and can decrease reliance on other expensive and time-consuming services at hospitals, enabling healthcare professionals to focus on patient care."

To Barbir, the effectiveness of Web Services in an enterprise depends on the kind of data that need to be accessed and who has access to it. "Web Services make sense" he says, when the value-add that they generate justifies their deployment. In some cases, such as accounting-related information that is restricted to very few people, there may not be any benefit."

Setting Standards
As Tuecke points out, there have been many instances in the past of technology--DCE, CORBA, DCOM, etc.--that promised benefits from distributed systems integration, much like those now touted for Web Services. "However," he adds, "each of those other technologies was only supported by some of the vendors. The tantalizing prospect of Web Services--beyond its technical capabilities--is ubiquity." The way to achieve that ubiquity is through standards.

"Basically," says Austin, "Web Services offers us a way to construct a well-defined, standards-based interface to software applications that works in a distributed environment. One might think of this as a 'generic API' for distributed computing applications. By using an easily managed interface definition [WSDL], incorporating discovery [via UDDI], and adopting a simple transport protocol [SOAP], we can build public interfaces to applications and application components. We can realize the benefits of distributed computing while avoiding a great deal of the chaos and difficulty involved in managing multiple interacting applications.

"As always," Austin continues, "the biggest problem is getting everyone, including the major implementers of Web Services technology, to agree on a set of standards that work for everybody." He adds that W3C, the major standards body for the Web, "arrived late to the table," but is now getting more involved and trying to coordinate efforts, though "several vendors are already offering existing implementations that they will be loathe to change."

W3C's activity in Web Services (www.w3.org/2002/ws/) is currently made up of one Coordination Group and three Working Groups. The Web Services Architecture Working Group is focusing on privacy and security as the "keys to the success of Web Services," and is identifying the technologies necessary for Web Services to be used, described, discovered, and to interact with each other. A working draft has been published on architecture requirements, and additional documents are in progress covering usage scenarios and a glossary. The Group also intends to develop a model of various Web Services concepts to ensure that various proposed specifications actually work together.

The Web Services Description Working Group, meanwhile, is chartered to design components of the interface, which it describes as "the boundary across which applications (Web Services user agents and Web Services) communicate." The group has published a draft of version 1.2 of WSDL, as well as drafts of description requirements and usage scenarios.

As for the XML Protocol Working Group, it is working on the creation of simple protocols that may be ubiquitously deployed and easily programmed. "The goal," according to the group's charter, "is a layered system that will directly meet the needs of applications with simple interfaces (e.g., getStockQuote, validateCreditCard), and which can be incrementally extended to provide the security, scalability, and robustness required for more complex application interfaces." The Group has published working drafts covering XML Protocol (XMLP) requirements and various aspects of SOAP Version 1.2.

Page 2 of 3