Web Services Explained, Solutions and Applications for the Real World
I've Heard This All Before Are Web Services for Real?
Information Systems executives have heard vendors and standards organizations pitch program-to-program distributed computing architectures for two decades.
For example, in the early 1980s IBM introduced its Systems Application Architecture (SAA) and a concept called "program-to-program" communications that had aims similar to those of Web services today. IBM had its own format for information transfer, Document Content Architecture (DCA), its own protocol for enabling programs to "speak" to each other: Logical Unit 6.2 [LU6.2 an application program interface (API)]; and its own protocol to bind sessions: peer-to-peer Physical Unit 2.1 (PU 2.1 a peer systems communications protocol).
Apollo had a program-to-program architecture based on Remote Procedure Calls (RPCs); Microsoft had one of its own (Distributed Network Architecture DNA); the Object Management Group introduced a solution called Common Object Request Broker Architecture (CORBA); the Open Software Foundation offered DCE, and so on.
Each of these architectures used the same basic approach: a common data format; a common suite of application program interfaces (APIs); and a common network environment. Today's Web services are architected in the same manner format, APIs, network communications protocols. For instance, IBM's architecture had a common content/format de facto standard (DCA as compared with Web services' XML content/format); a common API (LU 6.2 as compared with communications protocols found in WSDL and SOAP); and a common communications standard (PU 2.1 over an SNA-based protocol network as opposed to today's HTTP and TCP/IP protocols over the Internet).
So, are Web services just another distributed computing scheme? If not, why will Web services succeed where others have failed?
How Web Services Differ from Previous Architectures
The fundamental objective in distributed computing is the same now as it was 20 years ago: to enable applications to work cooperatively with other applications over a common network. This time, however, Web services:
Use fluid, as-needed, loosely coupled connections between applications. This loosely coupled approach means that applications can find each other and automatically request and recieve "services." This approach has very significant advantages (see Figure 0-2) over earlier distributed computing architectures that use a hard-coding method to link applications together.
Allow for the use of differing programming languages between cooperating programs (rather than requiring that programs all be written in the same language in order to interoperate).
Allow information to flow more smoothly through corporate networks and through supply chains (XML documents can move freely and securely though security firewalls).
Make it possible for applications to find each other and work cooperatively together (as opposed to having to "hard-code" the locations of cooperating programs in order to enable requester applications to find and work with service applications).
Have the advantage of one common network (the Internet) as opposed to multiple competing networks (such as SNA, TCP/IP, OSI, IPX/SPX, and other network schemes) to enable systems and applications to communicate with each other. Almost every distributed systems and applications vendor supports Internet communications.
By being able to find each other, Web services applications can request and obtain transactional, messaging, or computational services then recede until the service is again required. This fluid and dynamic approach makes Web services distinctly different from previous attempts to build a ubiquitous program-to-program communications architecture.