Writing Messaging-Type Applications

Messaging applications are entirely different from RPC-type messages. Messaging applications are based on the processing of XML documents. This means that there are no parameters and no object mappings. The developer is left to his own devices and needs to think of a different processing strategy. This is not a bad thing because messaging applications are better able to deal with variable data. A messaging application is coded in a similar way as a manually coded Web Service. One big difference that distinguishes a message-based Web Service and the Web Services defined thus far in the chapter is the deployment file.

Listing 10.43 is a sample messaging deployment file.

Listing 10.43

 <deployment name="test" xmlns="http://xml.apache.org/axis/wsdd/" xmlns:java="http://xml.apache.org/axis/wsdd/providers/java" xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance"> <service name="Message" provider="java:MSG"> <parameter name="className" value="com.devspace.jseng.ws.msg.Msg"/> <parameter name="allowedMethods" value="echoElements"/> </service> </deployment> 

 

In Listing 10.43, the deployment file is the smallest yet, and has only two lines at the basic minimum. This is entirely acceptable because messaging-based Web Services are very easy to configure. What is different in this deployment file is the attribute provider, which has a value of java:MSG The java:MSG value means that the Web Service is messaging- based and that all of the methods exposed by the Web Service have a specific method signature. The two parameter XML elements are similar to those used in previous deployment files in this chapter.

Listing 10.44 is the implementation of the messaging Web Service (note that the class has been abbreviated for clarity).

Listing 10.44

 public class Msg { public Element[] echoElements(Element[] elems) { Element[]result = new Element[ elems.length]; for ( int i = 0 ; i < elems.length ; i++ ) { Element bodyNode = elems[ i]; contentString = ""; parseCurrentNode( bodyNode); result[ i] = XMLUtils.StringToElement(  "urn:courseJWS", "result", contentString); } return( result ); } } 

 

In Listing 10.44, the method echoElements has an input parameter that is an array of the Element , and an output that is an array of the Element . The data type was not declared in the deployment file; in addition, there is no descriptor, because when a messaging Web Service is written using Axis, Axis expects that the Web Service consumes XML nodes. The class Element is an XML node with child nodes and attributes. In terms of an RPC processing-type architecture, the raw XML is the step before an RPC Web Service converts the data to Java objects. The individual Element class instances can be iterated and manipulated like another XML document. If desired, the developer could use the betwixt or digester package to process the XML nodes. In Listing 10.44, the individual XML documents are processed using the method parseCurrentNode . The method parseCurrentNode looks at the individual nodes and their content and returns a new XML document.

The client application is shown in Listing 10.45.

Listing 10.45

 class Client { public Element buildNode( String namespace, String text) throws Exception { Element embedded = XMLUtils.StringToElement( namespace, "greeting", text);  Document doc = embedded.getOwnerDocument(); Element element = doc.createElementNS( "default", "wrapper"); element.appendChild( embedded); return element; } public Element buildNode2( String identifier) throws Exception { Document doc = XMLUtils.newDocument(); Element element = doc.createElementNS( "default", "usertext"); Text textElement = doc.createTextNode( identifier); element.appendChild( textElement); return element; }   public String doit(String[] args) throws Exception { Options opts = new Options(args); opts.setDefaultURL("http://localhost:8081/axis/services/Message"); Serviceservice = new Service(); Call call= (Call) service.createCall(); call.setTargetEndpointAddress( new URL(opts.getURL()) ); SOAPBodyElement[] input = new SOAPBodyElement[3]; input[0] = new SOAPBodyElement( buildNode( "urn:English", "Hello")); input[1] = new SOAPBodyElement( buildNode( "urn:French", "Bonjour")); input[2] = new SOAPBodyElement( buildNode2( "Some text")); Vectorelems = (Vector) call.invoke( input ); SOAPBodyElement elem= null ; Element e = null ; elem = (SOAPBodyElement) elems.get(0); e= elem.getAsDOM(); String str = "Res elem[0]=" + XMLUtils.ElementToString(e) + "\n"; elem = (SOAPBodyElement) elems.get(1); e= elem.getAsDOM(); str = str + "Res elem[1]=" + XMLUtils.ElementToString(e) + "\n"; elem = (SOAPBodyElement) elems.get(2); e= elem.getAsDOM(); str = str + "Res elem[2]=" + XMLUtils.ElementToString(e) + "\n"; return( str ); } public static void main(String[] args) throws Exception { String res = (new Client()).doit(args); System.out.println(res); } } 

 

Listing 10.45 is a bit longer than the code for coding the Web Service client manually, shown in Listing 10.16. Listing 10.45 contains some old methods and some new ones. What's old is the preparation of the method call using the class Service and the method createCall . What's new is the use of the class SOAPBodyElement . In the specifications of the SOAP message, it was said that SOAP messages could contain multiple content elements. With RPC, there is only one content element. The class SOAPBodyElement represents an individual content element. In Listing 10.45, three body elements are created. The constructor to the class SOAPBodyElement accepts an XML document. The XML document is created using the methods buildNode and buildNode2 . The individual SOAPBodyElement class instances are stored in an array that is passed to the method invoke. The method invoke takes the individual content elements and generates a SOAP message that is sent to the Web Service provider. Listing 10.46 illustrates the sent SOAP message.

Listing 10.46

 <?xml version="1.0" encoding="UTF-8"?>  <soapenv:Envelope  xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"  xmlns:xsd="http://www.w3.org/2001/XMLSchema"  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Body>  <ns1:wrapper xmlns:ns1="default"> <ns2:greeting xmlns:ns2="urn:English">Hello</ns2:greeting>  </ns1:wrapper>  <ns3:wrapper xmlns:ns3="default"> <ns4:greeting xmlns:ns4="urn:French">Bonjour</ns4:greeting>  </ns3:wrapper>  <ns5:usertext xmlns:ns5="default">Some text</ns5:usertext> </soapenv:Body>  </soapenv:Envelope> 

 

In Listing 10.46, notice how each of the XML elements wrapper and usertext are wrapped in some namespace. The namespaces are created when the XML DOM method createElementNS is used. The Web Service server defined in Listing 10.44 would iterate the three documents and generate three new XML documents as a response. The response is shown in Listing 10.47.

Listing 10.47

 <?xml version="1.0" encoding="UTF-8"?>  <soapenv:Envelope  xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"  xmlns:xsd="http://www.w3.org/2001/XMLSchema"  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Body>  <ns1:result xmlns:ns1="urn:courseJWS"> Node name is (ns2:greeting)Text value is (Hello)  </ns1:result>  <ns2:result xmlns:ns2="urn:courseJWS"> Node name is (ns4:greeting)Text value is (Bonjour)  </ns2:result>  <ns3:result xmlns:ns3="urn:courseJWS">  Text value is (Some text)  </ns3:result> </soapenv:Body>  </soapenv:Envelope> 

 

In Listing 10.47, the returned XML documents are represented by the XML tag result . The results bear no resemblance to the input XML documents. That is OK and indicates the freeform nature of the XML documents. However, this does a raise a problem in the types of WSDL files, as shown in Listing 10.48.

Listing 10.48

 <wsdl:types> <schema targetNamespace=""> <import namespace="http://schemas.xmlsoap.org/soap/encoding/"/> <element name="echoElements" type="xsd:anyType"/> <element name="echoElementsReturn" type="xsd:anyType"/> </schema> </wsdl:types> 

 

In Listing 10.48, the schema XML tag references two XML tags element . The XML tag element is the definition of the input and output data types. In Listing 10.48, the data types are defined to be xsd:anyType , which means that the SOAP message can contain any kind of data. This is a problem because different Web Service implementations will translate the WSDL types differently. It does not mean that messaging Web Services are incompatible across implementations . What it means is that messaging Web Services require more tweaking to make the sender and receiver be able to communicate and exchange messages. You can use an XML Schema to define specific data types, but that would require manual definition. At that point, it would be very beneficial to use an XML editor like XMLSpy. XMLSpy is an excellent tool to manipulate XML Schemas and WSDL files using an XML IDE. However, XMLSpy is not Open Source and costs money.

When to Use Messaging or RPC

It is absolutely important to remember that both messaging Web Services and RPC techniques are useful. To illustrate the differences, consider the processing of a mortgage application. A mortgage application involves the buyer finding a home, contacting a bank, filling out a mortgage application, making a bid, getting the mortgage application approved, and signing the house purchase contract.

Finding a home could be as simple as looking in a newspaper or surfing the Web. In the case of surfing the Web, the homebuyer would define a query (such as price restrictions or location), submit the query, and get a result set. In this case, the best type of Web Service to use would be an RPC Web Service. The query and response type of Web Service, which depends only on the parameters sent by the query, is an easy way to manage RPC Web Service requests . No external information is required by the Web Service Server to process the query. Therefore, the infrastructure required to process the Web Service request is simple and manageable.

Once the buyer has found a house, he will make an appointment with his bank and discuss the possibility of purchasing the house. At that point, the banker will start a mortgage application and will enter the specific details regarding the house. The banker will enter details about the person (or persons) applying for the mortgage as well as details about the house. At this point, the banker is creating a portfolio of information that may or may not be identical for another mortgage application. In classical terms, the banker creates a folder with the name of the application and then adds the papers related to the mortgage. The banker and others who approve or inspect the mortgage add their pieces of paper and increase the complexity of the mortgage folder. At this point, a messaging Web Service would be better to use because the XML folder could be sent from one Web Service to another. Each Web Service would serve as a workflow station and perform some logic on the XML document. Of course, when the data moves between the workflow stations it would be stored in an XML database.