In the previous two chapters, we talked extensively about SOAP and the structure it delivers to web services. Not surprisingly, the adoption of SOAP’s messaging formats brought about a need to describe operational information in an equally structured way. WSDL was introduced to address this need.
WSDL is an XML grammar for describing a web service as a collection of access endpoints[8] capable of exchanging messages in a procedure- or document-oriented fashion. A WSDL document is a recipe used to automate the details involved in application-to-application communication.
On one level, WSDL is not that different from CORBA IDL or Microsoft IDL. They are all used to define the interfaces (method signatures) and datatypes for a discreet piece of programming logic.
On another level, WSDL is an altogether different beast, offering a degree of extensibility that has no parallel in the IDL specification. This extensibility allows WSDL to be used to:
Describe endpoints and their messages, regardless of the message format or network protocol used to exchange them.
Treat messages as abstract descriptions of the data being exchanged.
Treat port types as abstract collections of a web services’ operations. A port type can then be mapped to a concrete protocol and data format.
If you are feeling a bit dazed after reading these bullet items, it’s just the WSDL specification talking! We’ll offer fewer “scientific” definitions as we go along; don’t let the terms scare you away from this technology.
As the number of communication formats and protocols used on the Internet continues to increase, finding a standard way of describing how two machines should communicate with one another has become increasingly important. WSDL describes what a service does, how to invoke its operations, and where to find it. WSDL has created separate definitions and terminology for defining a web service, the communication endpoint where that web service exists, the legal format for input and output messages for the web service, and an abstract way to declare a binding to a concrete protocol and data format.
Everything defined within a WSDL file is abstract: it’s just the definition of parameters and constraints for how communication should occur at runtime. The web service implementation has to adhere to the guidelines defined in the WSDL file but has some flexibility over specifics. WSDL also provides the ability to define a binding that attaches an abstract set of message definitions to a concrete protocol or data format. A binding extension is a type of binding defined for a major protocol. WSDL defines out-of-the-box binding extensions for SOAP 1.1, HTTP GET, HTTP POST, and MIME.
Since WSDL is just an abstract description of a web service’s interface, it is conceivable that implementation code can be generated from a WSDL definition and that WSDL definitions can be created automatically from existing implementation code. From a programming perspective, using WSDL to generate code is one of its biggest values. Methods of generating WSDL from existing components have also been discovered. Both techniques are a boon to developers and nondevelopers alike and lend credibility to the notion of truly dynamic computing models.
The question that developers have to ask, however, is what they are going to build first. Will you build the service implementation first and then generate the interfaces automatically? Will you create the WSDL for a web service and then use a tool to create the matching J2EE base components necessary to implement the web service?
We feel that the model that will resonate most with developers is one that focuses on creating a web service and a specified set of input methods. Developers will create an implementation and make sure it works correctly; tools then take the basic implementation and generate WSDL files automatically. Most tools on the market today are capable of doing this. For example, Cape Clear’s CapeConnect allows you to create a web service; it generates the WSDL automatically. BEA’s WebLogic Server 6.1 allows you to create an EJB or a JMS Destination and provides Ant scripts to create the WSDL associated with the implementations. Sonic Software’s SonicXQ allows you to generate WSDL that is mapped to various services, or endpoints, which could represent JMS destinations, calls to WebLogic EJB Server, or a J2EE Connector. Other available industry tools available for working with WSDL include Systinet WASP, The Mind Electic’s GLUE, and IBM’s Web Services Toolkit.
Integration between Java and WSDL is discussed in more depth at the end of this chapter.