Alphabet SOAP
Specifics of each vendor's view of Web services vary based on each company's ideological perspective, but it's safe to define Web services as online modular applications that use consistent standards to provide seamless interfaces between multiple and distributed business processes.
There are, necessarily, common elements to each vendor's vision. Because it has already been recognised as the most desirable standard for interoperable data representation, XML is accepted as the most desirable method of data representation.
TCP/IP is the common transport mechanism, allowing seamless connectivity between internal networks and the internet. HTTP is used for data flow control.
SOAP (Simple Object Access Protocol) has dominated efforts to provide a consistent control interface between Web services. SOAP includes a number of specific HTTP headers designed to ease the flow of information through firewalls and proxies.
It also includes an XML schema that forces Web services components to comply with the tightly defined parameter and exception values that facilitate communication between software modules.
In many ways, SOAP is an improvement over the COM and CORBA modular application architectures that have become clumsy facilitators of integration between applications within local environments.
While COM and CORBA saddled developers with the not insignificant burden of carefully specifying inter-application interfaces, SOAP-based Web services obviate much of this requirement by using a significantly easier vocabulary based on standard Internet protocols and common methods for data representation.
If that sounds a lot like an API for tying an application into a standard environment, you're on the right philosophical track. Instead of providing an interface into a specific program, however, Web services encapsulate discrete business processes-hiding the specific back-end functionality and making it accessible to other applications through a raft of standardised connectors.
Web services are effectively the next step in the evolution of object-oriented development, which allowed developers to standardise module interfaces within an environment, but failed to provide a viable method for linking disparate environments.
"Object-oriented techniques like CORBA focused very much on procedure interoperability and nothing whatsoever on data interoperability," says Hal Stern, chief technology officer with iPlanet, the onetime Sun Microsystems-AOL joint venture that in March set out on its own to develop Sun's Open Net Environment (SunONE) Web services architecture.
"If I have complete gibberish, I can have all the objects I want but I won't be able to exchange data," Stern continues. Using existing OO models, he says, developers "ended up building an awful lot of context; there's not enough structure out of the box to make those things useful right away. By leveraging the Internet as a way of doing delivery, and by leveraging the Java environment as a way of providing a robust development and deployment platform, we overcame some of those. We've reduced the tare weight of [OO development]."
By taking over many of the arcane aspects ofdata exchange and presentation, Web services sugar-coat the challenge of truly distributed computing that has been so difficult to achieve in widespread practice.
Hooks into standards-based, server-side logic should ease many once unfathomably difficult integration tasks.
Business leaders, therefore, can use Web services to integrate applications based on well understood business functions rather than having to get bogged down with the vagaries of distributed application mechanisms. Typical Web services components might include modules for adjusting inventory, paying contractors, calculating and lodging tax, and so on.
