The fuss about "Web Services"
Recently, a spate of newly proposed and hotly debated XML applications and related protocols and messaging services have engendered quite a bit of heat, but not much light, on the subject of "Web Services." IBM (WebSphere), Microsoft (.NET), Sun Microsystems (J2EE and more), and other powerful companies are all racing to build environments to support Web services, and numerous vendor-neutral efforts in the same area are likewise underway. But what's the fuss really all about?
In a nutshell, a Web service is a special kind of application where some kind of Web-enabled user agent -- a browser is a good example, but other software for cell phones, PDAs, embedded systems, and so forth can also qualify -- enables a user anywhere on the Internet to interact with a meaningful combination of data and processing abilities to perform useful work. In current practice, this often means performing financial or commercial transactions (where data about funds and transfers is crucial, as are secure transactions processing services), or interacting with various databases (such as airline or other travel reservations, reviewing account histories, and so forth). In database-speak, however, this usually means that individuals are limited to specific "user views" of much larger collections of data, so that they can interact with information that's relevant to them, but are kept away from the vast majority of such data that has no bearing on their account, history, or particular needs.
Going forward, the notion of Web services promises to expand dramatically. It's already possible to perform security scans and anti-virus checks through user agents on the Web.
Likewise, an increasing number of applications are recasting themselves into Web-oriented subscription based services that permit users to obtain access not only to data that's completely current, but also to perform operations and activities that are likewise constantly updated. Microsoft itself is embroiled in serious controversy over a move to licensing its operating system and related software on a subscription basis, and it's possible to understand Windows Update services as an example of what certain Web-based services might be: a systematic scan of a system configuration and code base that produces a snapshot that is then compared to the "latest and greatest" versions of all components discovered, with the ability to select and download necessary updates, patches, and fixes.
In the XML world these days, a large number of XML applications (think special-purpose markup languages that offers ways to identify and specify services, information, and metadata) are under development to deal with various aspects of Web services. In future tips, I'll tackle some of these topics to try to add some detail to the broad view I'm presenting here, but for today, I simply want to provide a more formal description of Web services. Based on an outstanding article from XML.com by Martin Gudgin and Timothy Ewald entitled "Pork Barrel Protocols," (http://www.xml.com/pub/a/2001/09/12/porkbarrel.html) those authors define Web services as follows:
"We define a "web service" as an endpoint for communication that
- Uses standard high-level Internet communication protocols like HTTP or SMTP
- Transfers data using XML messages
- Describes its message types using a portable type system which is both language and platform neutral
- Provides a way to access metadata describing the messages it accepts"
In plainer terms, this means that Web services must use standard Internet methods to communicate to reach the broadest possible audiences (and work with standard software components like Web browsers and e-mail clients). Web services rely on XML because it provides a simple, powerful, and flexible way to capture and exchange data. These characteristics are unarguable, as the wide and growing range of XML applications for everything from genealogy to e-business transactions readily attest. Portable data typing and self-describing syntax, structures, and semantics are keys to building effective distributed services. Although fundamental standards and agreements on how to use them to create truly general, platform-neutral, easily accessible distributed services are still lacking, nobody doubts XML's abilities to define and provide such things. Though the devil indeed is in the details, this devil will surely get his due!
Thus, though many parallel and somewhat incompatible efforts to address Web services with XML tools and technologies are underway, it's just a matter of time before significant successes in this area demonstrate the power and capability of this model. As that happens, we'll all see growing evidence of the workability of the Web services model for ourselves. Properly implemented, they promise to reinvent everyday uses of networking and computing technologies. My belief: We ain't seen nothing yet, but we will -- and soon!
Have questions, comments, or feedback about this or other XML-related topics? Please e-mail me at firstname.lastname@example.org; I'm always glad to hear from my readers.
Ed Tittel is a principal at LANWrights, Inc., a wholly owned subsidiary of LeapIt.com. LANWrights offers training, writing, and consulting services on Internet, networking, and Web topics (including XML and XHTML), plus various IT certifications (Microsoft, Sun/Java, and Prosoft/CIW).