Darren Barefoot, Technology Evangelist @ CapeScience, September 9, 2002
| This article introduces Web services technologies and how they work together to create a Web services architecture. The intent is to provide a straightforward, hype-free and vendor-neutral explanation of the technology. You'll have an easier time reading this article if you're familiar with XML or have a background in programming, but it's certainly not essential. If you're relatively new to these technologies, check out some of the resources referred to throughout the article. They should help to clarify some of the more complex issues. |
|
Before Web services, Internet computing and e-commerce were based on the exchange of information through enterprise application integration (EAI). Developers created one-time, proprietary solutions for system integration. A new, often makeshift solution had to be developed each time two companies wanted to interchange data.
The introduction of Extensible Markup Language (XML) was an important step to simplifying the application integration process. XML enables developers to separate the content of data exposed over the Web from its presentation. A predefined markup language like HTML defines a way to describe information in one specific class of documents. XML, on the other hand, lets you define your own customized markup languages for different kinds of documents. This means that data can be easily exchanged, not only among humans through Internet browsers, but also among computers. More importantly, XML has been widely accepted as the universal language of choice for exchanging information over the Web and is a public format (that is, not the proprietary product of any company). As a result, individuals can develop new standards for specific functions based on XML or XML-based standards.
For further information about XML, check out the very readable
Introduction to XML from
Webmonkey.com. Not only is it easy to understand, but it also features an
explanation of XML based on a chocolate chip cookie recipe. For a more detailed
analysis of the technology, see
A Technical
Introduction to XML. Lastly, having promised a hype-free article, the
discerning reader should also stop by
XML Sucks to hear the other
side of the debate. This site features a
handy list
of the various flavours of XML-based technologies.
Web services have emerged as the next generation of Web-based technology for exchanging information. Web services are modular, self-describing, self-contained applications that are accessible over the Internet. Based on open standards, Web services enable you to build Web-based applications using any platform, object model, and programming language that you require. Put another way (thank you, Hari Mailvaganam), "Web Services allow any piece of software to communicate with a standardized XML messaging system."
The modularity and flexibility of Web services make them ideal for application integration. Businesses can mix and match Web services to with minimal programming. Web services can vary in function from simple requests (for example, currency conversion or a weather report) to complex business systems that access and combine information from multiple sources. Once a Web service is deployed, other applications and Web services can discover and invoke that service.
I was recently contacted at CapeScience by a company that wanted to use our GlobalWeather Web service in their commercial application. They were developing a reservations system for travel agents, and wanted their client application (in this case a JSP page) to display the current conditions for a given location based on its nearest airport code. While they are doing the majority of development in-house, they are integrating our freely-available Web service into their product. They might also add the aforementioned currency conversion Web service as well. This is a typical example of the modular application model that is central to Web services.
A technology introduction isn't complete without a bulleted benefits list. After all, why do you we adopt new stuff if not to enjoy some benefit? So, without further ado, here are five compelling reasons to use Web Services:
 |
|||
 |
|
 |
|
 |
|||
These benefits and laudatory quotations are all well and good, but, practically speaking, how can Web services actually help an organization? Consider a project that Cape Clear Software recently completed with salesforce.com, a customer relationship management (CRM) developer. Basically, Cape Clear developed several Web services that enabled data synchronization between salesforce.com and any SQL-compliant database. This meant that whenever data (for example, a billing address) was modified in salesforce.com, it would automatically be changed in related databases (such as a Microsoft Great Plains billing system). This loosely-coupled Web services solution replaced the previous manual system, which was fraught with inefficient multiple entry and susceptibility to errors.
To illustrate this solution, I've borrowed a couple of diagrams from Cape Clear's salesforce.com demo, which is the diagram below shows a pre-integration scenario for a purchase order process. It's not a pretty picture, with lots of manual and potentially error-ridden steps. Once a purchase order is entered into salesforce.com, it must also be manually entered in Microsoft Great Plains and a manufacturing system.
As shown in the following diagram, the implementation of a series of loosely-coupled Web services simplifies the entire process, enabling data to be updated in multiple locations in real time.
Now that we've come to grips with what Web services are and how they can help reduce the hassles of integration, the next section introduces the basic technologies behind Web services.
What's the point of technological innovation if you can't invent some cool acronyms? Web services have plenty of them. Having already discussed XML, there are three other important technologies that you should be familiar with:
WSDL is the metadata language of Web services. It acts as a ?user?s manual? for Web services, defining how service providers and requesters communicate with each other about Web services.
Like XML, WSDL is extensible to allow the description of endpoints and their messages, regardless of what message formats or network protocols are used for communicating. WSDL can be used to design specifications to invoke and operate Web services on the Internet and to access and invoke remote applications and databases.
Typically, if you want to create an application that communicates with a particular Web service, all you need is that service's WSDL file. In this way, WSDL files are similar to the Interface Definition Language (IDL) used by RPC and CORBA systems.
For more information (and, frankly, if you're having trouble getting to sleep), you can check out the WSDL specification at W3C. Additionally, there's a closer look at the structure of a WSDL file at WSDL: An Insight Out . Finally, if you're a Java developer, you may prefer to a more familiar perspective on your WSDL files.
SOAP is an XML-based protocol for exchanging information in a decentralized, distributed environment. It defines a mechanism to pass commands and parameters between clients and servers. Like Web services as a whole, SOAP is independent of the platform, object model, and programming language being used.
A particular advantage of SOAP over earlier protocols, such as Internet Inter-ORB Protocol (IIOP) for CORBA or Java Remote Method Protocol (JRMP) for Java Remote Method Invocation (RMI), is that it uses XML and is therefore text-based. This makes SOAP-based applications easier to debug, because it is obviously easier to read XML than to read a binary stream. Additionally, text-based protocols like SOAP over HTTP are firewall-friendly and tend not to create the same security issues as proprietary protocols.
Feeling masochistic? There's always the W3C SOAP 1.1 specification. For the rest of you eager beavers, take a look at A Young Person's Guide to the Simple Object Access Protocol.
UDDI is the meeting place for Web services. An information database of Web services, a UDDI registry stores descriptions about companies and the services they offer in a common XML format. Just as businesses list their products and services in a telephone directory, Web service brokers use this specification to register services that service requesters can then discover and invoke. Web-based applications interact with a UDDI registry using SOAP messages.
Conceptually, the data in a UDDI registry can be divided into three different types of telephone directories: a white-pages section that provides business contact information, a yellow-pages section that categorizes businesses and services, and a green-pages section that provides technical information about the services that a business offers. A typical example of UDDI usage is a stock-ticker application that can automatically locate a Web service that offers stock quotes using a standardized API.
As of mid-2002, UDDI has been the most-hyped and least-accepted of these technologies. It's not surprising--anything with 'universal' in its name is setting itself up for a fall. While public UDDI registries are in place, in my experience developers are not necessarily using them to discovery services. My colleagues and I are much more likely to go to a site like www.salcentral.com or www.xmethods.com and browse for the services we're seeking. This may be motivated by a general suspicion that the public UDDI registries are not fully populated with all of the available Web services. Alternately, it may just be a matter of familiarity. Before the yellow pages, people tended to rely upon trusted sources (friends, shopkeepers, and so on), so currently sites like XMethods (who also offers a UDDI interface) and SalCentral may be the most comfortable choice.
For more information about UDDI, visit uddi.org.
In a recent entry in his ultra-popular Weblog, Dave Winer explained that Web services are boring because "unless you're a programmer who likes to play in different environments, or likes to work with other programmers who work in different environments, or thinks the Internet is cool, even if he or she can't totally explain why. Web services are plumbing, and therefore to most non-programmers, off-topic."
Ironically, it is very nature of Web services as plumbing that makes them an important evolution in Internet computing. Imagine a neighborhood where each house connected to the city water supply using a different kind of pipe. Some are square, some are triangular; some require elbow joints, some don't. It's a plumber's nightmare, and, generally speaking, this was Internet computing before Web services. If the promise of Web services pays off, we'll have provided a universal bracket for all of these pipes, making it a lot easier to get a drink.