Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Cross Language Barriers with SOAP and a Java Web Service : Page 3

SOAP lives up to its promise of cross-language interaction.


advertisement

Why <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 xsi:type incompatibility.

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:


java org.apache.soap.server.ServiceManagerClient 
// 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.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date