A Layman’s Attempt to Digest “XML Web Services”
I rediscovered this note written during the spring of 2002, and decided to add it to my blog. The note was originally drafted to help me internalize readings on emerging Web Services. Maybe others will find this a helpful read.
What’s a web service?
There’s an incredible amount of hype on this topic at present (since 2001). Numerous books have been published in early 2002, including a series of O’Reilly titles, all dedicated to Web Services on the Sun J2EE platform (Java 2 Enterprise Edition) and the Microsoft .Net Framework. In the simplest terms, the emerging Web Services standards promise to simplify the sharing of data between software information systems over the Internet, using open rather than proprietary standards.
Integrated Software Experiences
From a lay perspective, we know that it’s very useful for distributed information systems, and even desktop applications to be able to easily exchange data. It’s great from a user’s perspective to work with a well integrated software system. Imagine if you could automatically extract financial information from all of your financial service providers (credit cards, banks, brokers) into your favorite financial planning software. It’s not reality because the scope of the human and software-based information systems involved is large. Strong integration has occured on the personal computer desktop, since that’s a more tractable domain, where the disparate systems involved all run on a single computer, and most often are used and adminstered by one person. The Microsoft Office suite would be a good example, where you are able to easily share data between a word processor, a spreadsheet, a presentation tool and even a web browser.
Two Paths to Integration
The benefits of an integrated software system can only be realized when the back-end systems are able to communicate with each other. This back-end communication must be standardized in some way to enable large numbers of software developers to write applications that can interoperate.
In the past, systems were integrated using proprietary, vendor specific APIs. This meant vendor “lock-in” for customers. For example, if you wanted a spreadsheet that interoperated well with a word-processor, it helped to buy both products from the same vendor. Developing integrated software is much easier when all the engineers work in close contact under unified leadership.
In the world of networked information systems, as opposed to isolated desktop applications, it also eased interoperability to buy solutions from a single vendor. This mode of industry practice helped software integration in the short-run, but seemed to stifle software innovation in the long run.
The information systems industry has since evolved toward open standards. These industry-wide standards enable companies to compete in the creation of software products without requiring monopoly power to provide interoperability. A pervasive global information system has evolved rapidly since the rise of the commercial Internet. To enable integrated software experiences on this scale, vendors do not entertain the notion of one solution provider winning over all others. Instead, they hope to agree on methods to enable these systems to communicate with each other. Hence we have the current landscape surrounding the standards for communication between distributed systems over the Internet, the standards intended to enable a future filled with “web services”.