WSDL | XML, Web Services, and the Data Revolution


Team-Fly

	XML, Web Services, and the Data Revolution By Frank P. Coyle
	Table of Contents

	Chapter 5. Web Services

WSDL: how to connect to providers.

WSDL is the piece of the Web services framework that describes how to connect to Web services providers. WSDL is an XML format for describing how one software system can connect and utilize the services of another software system over the Internet. The WSDL specification supports the building of Web-based computing services that target computer programs rather than human users. WSDL uses an XML-based syntax to describe the specifics of accessing a Web service, such as the type and number of parameters passed to a service and the type and structure of the result returned.

Once a Web service has been discovered (via UDDI), WSDL provides the details of how to actually bind and interact with that service.WSDL supports direct client interaction with a Web service provider by building on the infrastructure provided by HTTP and SOAP. However, it is important to note that WSDL is not directly dependent on SOAP and HTTP. The WSDL specification also provides example mappings of WSDL descriptions onto a number of other Web protocols that can be used for passing parameters and results, including URL-encoded parameter passing in HTTP and multipart Multi-Purpose Internet Mail Extensions transported via HTTP.

WSDL ports define data bindings.

WSDL defines services as collections of network endpoints or ports. Figure 5.4 illustrates that in WSDL the abstract definition of endpoints and messages is separated from their concrete network-based data bindings. Abstracting away specific connection details allows reuse of abstract definitions of messages, which themselves are abstract descriptions of the data being exchanged. Also in this picture are port types, which are abstract collections of operations.

Figure 5.4. The structure of a WSDL document.

graphics/05fig04.jpg

In WSDL, the concrete protocol and data format specifications for a particular port type constitute a reusable binding. A port is defined by associating a network address with a reusable binding. In this way, the reusable abstraction is brought together with a concrete implementation allowing for implementation details to change while keeping the service abstraction the same.

A ZwiftBooks WSDL Example

ZwiftBooks defines its WSDL so clients can connect.

ZwiftBooks has decided to move its service offering into the realm of Web services and to develop a WSDL description that others can use to connect to a ZwiftBooks server to find the time of delivery for a book within a specific zip code. For ZwiftBooks, the basic idea is to describe not just the messages used in a communication exchange but to tie them together as request-response pairs.

Port Types and Operations

In WSDL, the messages between client and server are described by defining an operation element that specifies which message serves as the input and which message acts as the output, as in the following example:

 <operation name='GetDeliveryInfo'     parameterOrder='zipcode isbn'>     <input message='wsdlns:ZBooks.GetDeliveryInfo'/>     <output     message='wsdlns:ZBooks.GetDeliveryInfoResponse'/> </operation>

Note that the operation element specifies the request and response as input and output elements. Each refers to a corresponding message by its fully qualified name, such as wsdlns:ZBooks. Get DeliveryInfo .

In WSDL, the collection of all operations (that is, methods ) exposed by the ZwiftBooks service is called a portType and is defined using the WSDL portType element, which packages the operation element.

 <portType name='ZBooksSoapPort'> <operation name='GetDeliveryInfo'     parameterOrder='zipcode isbn>     <input message='wsdlns:ZBooks.GetDeliveryInfo'/>     <output     message='wsdlns:ZBooks.GetDeliveryInfoResponse'/> </operation> <!-- other ZwiftBooks operations would be listed here --> </portType>

From Abstraction to Reality

WSDL bindings represent concrete connections.

In the above example we've described in abstract terms what a ZwiftBooks service does. However, nothing has been said about how a client is expected to deliver an ISBN number or a zipcode. Should they be in the form of integers, strings, or special data types? Because WSDL messages rely on SOAP for delivery, and because SOAP uses XML Schema for data types, WSDL also relies on XML Schema. Thus, to define the concrete aspects of an operation, we use the WSDL binding element:

 <binding name='ZBooksSoapBinding'     type='wsdlns:ZBooksSoapPort' > . . . </binding>

The binding name is arbitrary, but the name for the binding attribute on the port element must match whatever name we use here. Inside the binding element there is a WSDL SOAP extension element called soap:binding that is used to specify the transport protocol ”such as HTTP, Simple Mail Transport Protocol (SMTP), or FTP ”and whether we want clients to invoke a remote procedure call (RPC) at our site or just send an XML document.

For example, to indicate to potential clients that they should invoke a method on our ZwiftBooks server, we add the style='rpc' attribute and value to the soap:binding element:

 <soap:binding style='rpc'         transport='http://schemas.xmlsoap.org/soap/http'/>

To define an operation, we add an operation element with the same name as the previously defined operation. Within this operation element, we now add a soap:operation element with the soapAction attribute. Finally, we must specify how the input and output messages of this operation are encoded. The complete binding looks like this:

 <binding name='ZBooksSoapBinding'          type='wsdlns:ZBooks SoapPort'>  <soap:binding      style='rpc'      transport='http://schemas.xmlsoap.org/soap/http'/>  <operation name='GetDeliveryInfo'>  <soap:operation   soapAction='http://zbooks.org/action/ZBooks.               GetDeliveryInfo'/>   <input>     <soap:body       use='encoded'       namespace='http://zbooks.org/message/'       encodingStyle='http://schemas.xmlsoap.org/soap/                      encoding/'/>   </input>   <output>     <soap:body      use='encoded'      namespace='http://zbooks.org/message/'      encodingStyle='http://schemas.xmlsoap.org/soap/                     encoding/'/>   </output>  </operation> </binding>

Within the operation we add input and output elements and a soap:body element to specify the actual data encoding. The URI http://schemas.xmlsoap.org/soap/encoding/ indicates the SOAP encoding style as described in the SOAP specification. Now the WSDL file is complete and ZwiftBooks clients can begin to use it to figure out how to connect to the ZwiftBooks SOAP server and begin to use ZwiftBooks services. While there are many steps and pieces involved in defining a WSDL descriptor of a service, much of the complexity is handled by support tools that are part of Web Services delivery environments.

Web Services Caveats

Web services risks.

The Web services effort to take the Web to new levels of server-to-server interaction is generating significant excitement across the software industry. Web services is a unique venture that sees competitive rivals coming together to evolve a technology in parallel, with vendors pushing the technology and setting standards. However, as with any technological innovation, while it addresses some immediate problems of the past, it comes with new problems of its own that we must recognize and understand, lest we rush in blindly. For Web services there are a number of risks (see Figure 5.5).

Figure 5.5. The pros and cons of Web services.

graphics/05fig05.jpg

Maturity

Different implementations may not work together.

There is always risk in being an early adopter of any new technology. The key building blocks underlying Web services ”UDDI, SOAP, and WSDL ”are based on written English-language specifications, and there is risk that implementations from different vendors will suffer incompatibilities.

Security

SOAP messages on port 80 bypass firewalls.

Security is essential to a thriving e-commerce world and, while Web services does not specifically address security issues, the fact that it operates over the Web means that it can utilize existing Web secure communication capabilities such as the Secure Sockets Layer and X.509 protocols. However, because SOAP running over HTTP will use the standard Web server port 80, it places new burdens on system administrators to deal with traffic that easily moves through firewalls.

Another issue related to security involves XML, which is at the heart of all Web services communication, via SOAP, UDDI, WSDL, and the delivery of XML data. While at one level XML is just data, there are special security issues that are particular to XML that must be addressed by both users and providers of Web services. For example, I may want to encrypt or digitally sign only part of a SOAP message because I want a SOAP intermediary to be able to add something to the message but not read a small part I want to keep secret. These new issues arise with Web services because of XML and SOAP. (See Chapter 7 for details.)

Transactions

Transactions must be specified outside the Web services framework.

The ability to wrap Web services in transactions is critical to its success. Without the all-or-none property of complex interactions, it's not possible to do serious e-business on the Web. While Web services does not itself address transactions as part of the Web services initiative, transactional capabilities are available by integrating Web services with the opportunities provided by middleware frameworks ”such as .NET or Java 2 Enterprise Edition ”or by connections to mainframe-based transaction monitors such as Customer Information Control System. These issues are discussed in more detail in Chapter 6.

Configuration Management

Change management is not addressed.

Configuration management has been a nasty problem for software since the first commercial program went from release 1.0 to release 1.1. For complex software products, keeping compatible versions of constantly evolving modules in sync with each other is a continual, nagging problem. Many of the frustrations with the Windows operating system come after installing new software and experiencing the agony of "DLL Hell," as it's affectionately referred to in the industry. The dynamic link library (DLL) problem occurs when installing new software that requires updates to one or more system DLLs. After the updates are made, existing software that requires the older DLL no longer works because it has not been updated to handle the new DLL. It's a tricky problem with no easy solution.

There is a similar potential problem lurking behind Web services. For example if company X provides a Web service that depends on a Web service from company Y, and company Y changes the interface to its service, then unless company X receives notice of the change in time to adjust its own software, company X's Web service will fail.


Team-Fly

Top