Roger Wolter
Microsoft Corporation
December 2001
Summary: An overview of the value of XML Web services for developers, with introductions to SOAP, WSDL, and UDDI. (6 printed pages)
What Is an XML Web Service?
SOAP
WSDL
UDDI
What‘s Left?
XMLWeb services are the fundamental building blocks in the move todistributed computing on the Internet. Open standards and the focus oncommunication and collaboration among people and applications havecreated an environment where XML Web services are becoming the platformfor application integration. Applications are constructed usingmultiple XML Web services from various sources that work togetherregardless of where they reside or how they were implemented.
Thereare probably as many definitions of XML Web Service as there arecompanies building them, but almost all definitions have these thingsin common:
I‘ll coverall three of these technologies in this article but first I want toexplain why you should care about XML Web services.
One of theprimary advantages of the XML Web services architecture is that itallows programs written in different languages on different platformsto communicate with each other in a standards-based way. Those of youwho have been around the industry a while are now saying, "Wait aminute! Didn‘t I hear those same promises from CORBA and before thatDCE? How is this any different?" The first difference is that SOAP issignificantly less complex than earlier approaches, so the barrier toentry for a standards-compliant SOAP implementation is significantlylower. Paul Kulchenko maintains a list of SOAP implementations at: http://www.soapware.org/directory/4/implementationswhich at last count contained 79 entries. You‘ll find SOAPimplementations from most of the big software companies, as you wouldexpect, but you will also find many implementations that are built andmaintained by a single developer. The other significant advantage thatXML Web services have over previous efforts is that they work withstandard Web protocols—XML, HTTP and TCP/IP. A significant number ofcompanies already have a Web infrastructure, and people with knowledgeand experience in maintaining it, so again, the cost of entry for XMLWeb services is significantly less than previous technologies.
We‘vedefined an XML Web service as a software service exposed on the Webthrough SOAP, described with a WSDL file and registered in UDDI. Thenext logical question is. "What can I do with XML Web services?" Thefirst XML Web services tended to be information sources that you couldeasily incorporate into applications—stock quotes, weather forecasts,sports scores etc. It‘s easy to imagine a whole class of applicationsthat could be built to analyze and aggregate the information you careabout and present it to you in a variety of ways; for example, youmight have a Microsoft® Excel spreadsheet that summarizes your wholefinancial picture—stocks, 401K, bank accounts, loans, etc. If thisinformation is available through XML Web services, Excel can update itcontinuously. Some of this information will be free and some mightrequire a subscription to the service. Most of this information isavailable now on the Web, but XML Web services will make programmaticaccess to it easier and more reliable.
Exposing existingapplications as XML Web services will allow users to build new, morepowerful applications that use XML Web services as building blocks. Forexample, a user might develop a purchasing application to automaticallyobtain price information from a variety of vendors, allow the user toselect a vendor, submit the order and then track the shipment until itis received. The vendor application, in addition to exposing itsservices on the Web, might in turn use XML Web services to check thecustomer‘s credit, charge the customer‘s account and set up theshipment with a shipping company.
In the future, some of themost interesting XML Web services will support applications that usethe Web to do things that can‘t be done today. For example, one of theservices that XML Web Services would make possible is a calendarservice. If your dentist and mechanic exposed their calendars throughthis XML Web service, you could schedule appointments with them on lineor they could schedule appointments for cleaning and routinemaintenance directly in your calendar if you like. With a littleimagination, you can envision hundreds of applications that can bebuilt once you have the ability to program the Web.
For more information on XML Web services and the applications they will help you build, please see the MSDN XML Web Services Developer Center.
Soapis the communications protocol for XML Web services. When SOAP isdescribed as a communications protocol, most people think of DCOM orCORBA and start asking things like, "How does SOAP do objectactivation?" or "What naming service does SOAP use?" While a SOAPimplementation will probably include these things, the SOAP standarddoesn‘t specify them. SOAP is a specification that defines the XMLformat for messages—and that‘s about it for the required parts of thespec. If you have a well-formed XML fragment enclosed in a couple ofSOAP elements, you have a SOAP message. Simple isn‘t it?
Thereare other parts of the SOAP specification that describe how torepresent program data as XML and how to use SOAP to do RemoteProcedure Calls. These optional parts of the specification are used toimplement RPC-style applications where a SOAP message containing acallable function, and the parameters to pass to the function, is sentfrom the client, and the server returns a message with the results ofthe executed function. Most current implementations of SOAP support RPCapplications because programmers who are used to doing COM or CORBAapplications understand the RPC style. SOAP also supports documentstyle applications where the SOAP message is just a wrapper around anXML document. Document-style SOAP applications are very flexible andmany new XML Web services take advantage of this flexibility to buildservices that would be difficult to implement using RPC.
Thelast optional part of the SOAP specification defines what an HTTPmessage that contains a SOAP message looks like. This HTTP binding isimportant because HTTP is supported by almost all current OS‘s (andmany not-so-current OS‘s). The HTTP binding is optional, but almost allSOAP implementations support it because it‘s the only standardizedprotocol for SOAP. For this reason, there‘s a common misconception thatSOAP requires HTTP. Some implementations support MSMQ, MQ Series, SMTP,or TCP/IP transports, but almost all current XML Web services use HTTPbecause it is ubiquitous. Since HTTP is a core protocol of the Web,most organizations have a network infrastructure that supports HTTP andpeople who understand how to manage it already. The security,monitoring, and load-balancing infrastructure for HTTP are readilyavailable today.
A major source of confusion when gettingstarted with SOAP is the difference between the SOAP specification andthe many implementations of the SOAP specification. Most people who useSOAP don‘t write SOAP messages directly but use a SOAP toolkit tocreate and parse the SOAP messages. These toolkits generally translatefunction calls from some kind of language to a SOAP message. Forexample, the Microsoft SOAP Toolkit 2.0 translates COM function callsto SOAP and the Apache Toolkit translates JAVA function calls to SOAP.The types of function calls and the datatypes of the parameterssupported vary with each SOAP implementation so a function that workswith one toolkit may not work with another. This isn‘t a limitation ofSOAP but rather of the particular implementation you are using.
Byfar the most compelling feature of SOAP is that it has been implementedon many different hardware and software platforms. This means that SOAPcan be used to link disparate systems within and without yourorganization. Many attempts have been made in the past to come up witha common communications protocol that could be used for systemsintegration, but none of them have had the widespread adoption thatSOAP has. Why is this? Because SOAP is much smaller and simpler toimplement than many of the previous protocols. DCE and CORBA forexample took years to implement, so only a few implementations wereever released. SOAP, however, can use existing XML Parsers and HTTPlibraries to do most of the hard work, so a SOAP implementation can becompleted in a matter of months. This is why there are more than 70SOAP implementations available. SOAP obviously doesn‘t do everythingthat DCE or CORBA do, but the lack of complexity in exchange forfeatures is what makes SOAP so readily available.
The ubiquityof HTTP and the simplicity of SOAP make them an ideal basis forimplementing XML Web services that can be called from almost anyenvironment. For more information on SOAP, see the MSDN SOAP home page.
Oneof the first questions newcomers to SOAP ask is how does SOAP deal withsecurity. Early in its development, SOAP was seen as an HTTP-basedprotocol so the assumption was made that HTTP security would beadequate for SOAP. After all, there are thousands of Web applicationsrunning today using HTTP security so surely this is adequate for SOAP.For this reason, the current SOAP standard assumes security is atransport issue and is silent on security issues.
When SOAPexpanded to become a more general-purpose protocol running on top of anumber of transports, security became a bigger issue. For example, HTTPprovides several ways to authenticate which user is making a SOAP call,but how does that identity get propagated when the message is routedfrom HTTP to an SMTP transport? SOAP was designed as a building-blockprotocol, so fortunately, there are already specifications in the worksto build on SOAP to provide additional security features for Webservices. The WS-Security specification defines a complete encryption system.
WSDL(often pronounced whiz-dull) stands for Web Services DescriptionLanguage. For our purposes, we can say that a WSDL file is an XMLdocument that describes a set of SOAP messages and how the messages areexchanged. In other words, WSDL is to SOAP what IDL is to CORBA or COM.Since WSDL is XML, it is readable and editable but in most cases, it isgenerated and consumed by software.
To see the value of WSDL,imagine you want to start calling a SOAP method provided by one of yourbusiness partners. You could ask him for some sample SOAP messages andwrite your application to produce and consume messages that look likethe samples, but this can be error-prone. For example, you might see acustomer ID of 2837 and assume it‘s an integer when in fact it‘s astring. WSDL specifies what a request message must contain and what theresponse message will look like in unambiguous notation.
Thenotation that a WSDL file uses to describe message formats is based onthe XML Schema standard which means it is both programming-languageneutral and standards-based which makes it suitable for describing XMLWeb services interfaces that are accessible from a wide variety ofplatforms and programming languages. In addition to describing messagecontents, WSDL defines where the service is available and whatcommunications protocol is used to talk to the service. This means thatthe WSDL file defines everything required to write a program to workwith an XML Web service. There are several tools available to read aWSDL file and generate the code required to communicate with an XML Webservice. Some of the most capable of these tools are in MicrosoftVisual Studio® .NET.
Many current SOAP toolkits include tools togenerate WSDL files from existing program interfaces, but there are fewtools for writing WSDL directly, and tool support for WSDL isn‘t ascomplete as it should be. It shouldn‘t be long before tools to authorWSDL files, and then generate proxies and stubs much like COM IDLtools, will be part of most SOAP implementations. At that point, WSDLwill become the preferred way to author SOAP interfaces for XML Webservices.
An excellent description of WSDL is available, and you can find the WSDL specification at http://www.w3.org/TR/wsdl.
UniversalDiscovery Description and Integration is the yellow pages of Webservices. As with traditional yellow pages, you can search for acompany that offers the services you need, read about the serviceoffered and contact someone for more information. You can, of course,offer a Web service without registering it in UDDI, just as you canopen a business in your basement and rely on word-of-mouth advertisingbut if you want to reach a significant market, you need UDDI so yourcustomers can find you.
A UDDI directory entry is an XML filethat describes a business and the services it offers. There are threeparts to an entry in the UDDI directory. The "white pages" describe thecompany offering the service: name, address, contacts, etc. The "yellowpages" include industrial categories based on standard taxonomies suchas the North American Industry Classification System and the StandardIndustrial Classification. The "green pages" describe the interface tothe service in enough detail for someone to write an application to usethe Web service. The way services are defined is through a UDDIdocument called a Type Model or tModel. In many cases, the tModelcontains a WSDL file that describes a SOAP interface to an XML Webservice, but the tModel is flexible enough to describe almost any kindof service.
The UDDI directory also includes several ways tosearch for the services you need to build your applications. Forexample, you can search for providers of a service in a specifiedgeographic location or for business of a specified type. The UDDIdirectory will then supply information, contacts, links, and technicaldata to allow you to evaluate which services meet your requirements.
UDDIallows you to find businesses you might want to obtain Web servicesfrom. What if you already know whom you want to do business with butyou don‘t know what services are offered? The WS-Inspection specificationallows you to browse through a collection of XML Web services offeredon a specific server to find which ones might meet your needs.
More information about UDDI is available at http://www.uddi.org/about.html.
Sofar we‘ve talked about how to talk to XML Web services (SOAP), how XMLWeb services are described (WSDL) and how to find XML Web services(UDDI). These constitute a set of baseline specifications that providethe foundation for application integration and aggregation. From thesebaseline specifications, companies are building real solutions andgetting real value from them.
While much work has been done tomake XML Web services a reality, more is needed. Today, people arehaving success with XML Web services, but there are still things thatare left as an exercise for the developer®e.g. security, operationalmanagement, transactions, reliable messaging. The Global XML WebServices Architecture will help take XML Web services to the next levelby providing a coherent, general purpose model for adding new advancedcapabilities to XML Web services which is modular and extensible.
WS-Securityis one of the specifications in the Global Web Services Architecture.Operational management needs such as routing messages among manyservers and configuring those servers dynamically for processing arealso part of the Global Web Services Architecture, and are met by the WS-Routing specification and the WS-Referral specification. As the Global Web Services Architecture grows, specifications for these and other needs will be introduced.
More information is available on the Global XML Web Services Architecture.
联系客服
