isd:mappings> Are Important
Because XML is a text-based format, you need to convert values to and from text form to the proper types. To control the serialization and deserialization of specific Java types to and from XML in a particular encoding style, you may need to provide serialization and deserialization classes that know how to perform the correct conversions for those types.
The Apache-SOAP server already includes serialization classes for most basic types in a SOAP encoding style, as well as a Bean encoding class that provides generic bean serialization by serializing public properties. Apache-SOAP always includes
xsi:type elements for all the request parameters, and it expects
xsi:type elements in the response. However, the Microsoft SOAP implementation does not recognize
xsi:type elements. Because the example Web service is a Java class and the client is Visual Basic, the server uses Apache SOAP and the client uses Microsoft SOAP. Therefore, you must handle this
The Apache SOAP implementation expects requests to contain xsi:type elements. When they're not present, the server rejects the request, so the service request fails. In the descriptor file, the <isd:mappings> element removes the
xsi:type restriction for Apache SOAP, because it maps the XML element "name" to the StringDeserializer class. The StringDeserializer class transforms the contents of the XML element into an instance of
java.lang.String. Using this kind of explicit mapping, Apache SOAP doesn't have to look for
xsi:type elements in the request to provide the mapping information; instead, it assumes that all XML "name" elements are of type String and deserializes them appropriately.
With the deployment descriptor now completed, execute the following command to deploy the Java Web service:
// NOTE: The URL below should be a single line of code
http://localhost:8080/soap/servlet/rpcrouter deploy HelloServiceDeployment.xml
After running this command, you've completed the server part of this example.
Describe Your Web Service with WSDL
For clients to be able to call a Web service they need to know the available method names, the parameter names and types, and the expected output type for each method. Therefore, you need to generate some kind of interface that can sit between the server and client so each can understand the other's request or response. The Web Services Description Language (WSDL) fulfills these interface requirements.
WSDL, officially, is an XML grammar that contains information about the interface and semantics of a call to a Web service. But you can think of a WSDL file as an XML document that describes a set of SOAP messages, and how those messages are exchanged. In other words, WSDL is to SOAP as Interface Definition Language (IDL) is to CORBA or COM. Because WSDL is also XML, it is humanly readable and editable.
After developing a Web service, you publish its description and a link to it in a UDDI (Universal Description, Discovery and Integration) repository so that potential users can find it. When someone thinks they want to use your service, they request your WSDL file to find out the details for using the service. They then use the information in your WSDL file to form a SOAP request message.
The WSDL file is the heart of the Web service transaction, because without it the clients can't communicate with your Web service. To understand the value of WSDL, imagine you want to start calling a SOAP method provided by one of your business partners. You could ask him for some sample SOAP messages and write your application to produce and consume messages that look like the samples, but that can be error-prone. For example, you might see a customer ID of 8907 and assume it's an integer when in fact it's a string. The WSDL file specifies the contents of request and response messages unambiguously.
You can view the WSDL file for the example Web service here. See the sidebar "The WSDL Specification" for more information about the WSDL grammar.