 |
| |
| A Sacrifice to the Acronym God (cont.)
|
The Four Key Building Blocks
With an understanding of what Web services are all about, we can examine the core technologies that make Web services work. Those technologies are SOAP, XML-RPC, WSDL, and UDDI.
SOAP—The Simple Object Access Protocol is, according the 1.1 specification, "a lightweight protocol for exchange of information in a decentralized, distributed environment." The protocol is entirely based upon XML, is vendor-neutral, and is one of the cornerstone technologies in Web services. It represents the invocation mechanism within a Web service architecture.
SOAP is a specialized XML format that facilitates the exchange of messages in an asynchronous, platform-neutral manner. This communication can be a one-way asynchronous message, or a two-way RPC-style invocation. SOAP boasts a robust data-typing mechanism based on the XML Schema specification, XML Namespace support, as well as enterprise extensibility via SOAP headers. Although SOAP is based on XML and it is considered lightweight, it is actually quite heavyweight in terms of its resource demands, especially when compared to XML-RPC. If, however, bandwidth and processing power are not an issue (and they are become less significant every day), then SOAP offers a more robust and flexible Web services communication protocol.
XML-RPC—XML-RPC is a Remote Procedure Calling protocol that invokes remote procedures over the Internet by sending XML-formatted messages. XML-RPC is an extremely lightweight mechanism that can be used as the message format for the invocation layer of a Web service architecture. It is a lightweight alternative to SOAP that is especially useful when security and transaction support are less important than speed and simplicity.
The key to a Web service architecture is the utilization of XML as a language-agnostic, vendor- and platform-neutral medium for accessing Internet or intranet services. XML-RPC provides the minimum functionality necessary to specify data types, pass parameters, and invoke remote procedures in a neutral way.
WSDL—The Web Services Description Language (WSDL) is an XML-formatted interface for a Web service that describes what a Web service is capable of and how a client can locate and invoke that service. A service description can be published as a WSDL document, and therefore WSDL operates in the publishing layer of a Web service architecture. Graham Glass, founder and CEO of the Mind Electric, compares Web services and the role of WSDL to the human labor market:
"Job sites and recruiting companies provide a matchmaker service between workers and employers, utilizing résumés and job descriptions to facilitate the matching process. If a good match is found, the interested parties attempt to negotiate acceptable terms. If an agreement is reached, the worker either moves to the employer's location or takes advantage of the Internet and telecommutes instead. The Web Services Description Language is the XML equivalent of a résumé—it describes what a Web service can do, where it resides, and how to invoke it. In a nutshell, WSDL is the IDL of Web services." (from The Web Services Revolution Part 4: Web Services Description Language)
UDDI—Universal Description Discovery and Integration (UDDI) specification. There are two ways of finding a Web site on the Internet: directly typing in the URL, and using a search engine to locate a site that meets the criteria you provide. Because Web services operate over the Internet or a corporate intranet, locating them is done in the exact same way: you must either know the network address for the service, or use the Web services equivalent of a search engine.
If you already know the address of the Web service you want to invoke, or the address of its interface (WSDL, some flavor of XML, standard Java interface, etc.), then you can contact that service directly. This typically occurs in a corporate intranet, or a B2B extranet in which you might share the addresses of important services with your business partners. However, if you do not already know the address of the service, or its interface, then you must search for the service by querying a Web service registry. The UDDI spec defines a standard mechanism for publishing and locating the existence of businesses and the services they provide.
Putting the Blocks Together
To pull it all together, a simple Web service exchange involves the sending of a SOAP request (most likely via HTTP) to a SOAP service. This service would then parse the SOAP message, process the contents (perhaps extracting parameters and a specific service call), and optionally send a response SOAP message back to the client. If SOAP's asynchrony and flexibility are not necessary, however, this same exchange could be accomplished via XML-RPC. A more involved Web service exchange involves the querying of a UDDI registry in search of a compatible service, the retrieval of a WSDL document describing the service, the construction of a client to access the service, and then finally the invocation of that service.
|
|
|
FEATURE SOFTWARE:
dtSearch Web
Add power searching to your web site.
Buy Now!
Encrypt It
Encrypt and Decrypt Data, Passwords and Files within your application.
Buy Now!
|
|
|
Introduction
Other Must-Know Groups, Standards, and Terms
The Four Key Building Blocks
