WSDL breaks down Web services into three specific, identifiable elements that can be combined or reused once defined. Mapping from existing applications means mapping to these elements, which identify the contents and data types of the messages, the operations performed for the messages, and the specific protocol bindings, or transports, for exchanging the messages with the operations over the network. Within these elements are further subelements, or parts:
Data types: the data types—in the form of XML schemas or possibly some other mechanism—to be used in the messages
Message: an abstract definition of the data, in the form of a message presented either as an entire document or as arguments to be mapped to a method invocation
Operation: the abstract definition of the operation for a message, such as naming a method, message queue, or business process, that will accept and process the message
Port type: an abstract set of operations mapped to one or more end points, defining the collection of operations for a binding; the collection of operations, because it is abstract, can be mapped to multiple transports through various bindings
Binding: the concrete protocol and data formats for the operations and messages defined for a particular port type
Port: a combination of a binding and a network address, providing the target address of the service communication
Service: a collection of related end points encompassing the service definitions in the file; the services map the binding to the port and include any extensibility definitions
WSDL files can be divided into up to three separate, reusable elements
Fortunately, these parts of WSDL usually are generated using tools that transform the existing back-end application metadata into XML schema information, which is then merged into the Web Services Desciption Language file. WSDL is typically generated by Web services products and tools, such as IONA's XMLBus Edition.3
WSDL parts usually are generated automatically using Web services–aware tools
IONA's XMLBus Edition provides several options for Web service generation. Figure 3-2 shows the Edition's main menu, which is displaying the list of sample demos included with the product.4 These demos are prebuilt services, previously generated from Java classes and EJBs. The Edition also builds new Web services from Java classes, JavaBeans, and CORBA objects.
Figure 3-2. The XMLBus Edition's main menu lists the product's demos.
When building a new Web service, the Edition gathers necessary input and automatically generates the corresponding WSDL file.
The IONA XMLBus product builds a Web service using input forms such as the one in Figure 3-3, which asks the user to select the specific Java class methods for which a Web service is to be generated. The form also asks the user to select the document-oriented or RPC-oriented interaction style and to select either SOAP encoding5 or literal encoding—XML/text—for the service. Attachments are supported for the document-oriented style. Another form allows the user to input a specific namespace for the service instead of having it generated by the product. Finally, the user can generate either a proxy client for Java 2 Platform, Micro Edition (J2ME) devices, such as PDAs or mobile phones, or a regular Java proxy. Most Web service implementers, such as IBM and Microsoft, offer similar tools for automatically generating WSDL schemas, proxies, and namespaces.
Figure 3-3. Forms are used to select methods and interaction style to build a Web service.