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
 

Leverage JNLP and SOAP for Java Thick-client Development : Page 2

Although Java never quite lived up to its early promise of thick-client computing on the Web, intranets can benefit from the capabilities the JNLP protocol affords—especially when combined with the SOAP protocol.


advertisement

WEBINAR: On-Demand

Unleash Your DevOps Strategy by Synchronizing Application and Database Changes REGISTER >

Apache Axis or JAX-RPC: Which API Should I Use?
As with most standards, you have several choices among libraries that support XML-based messaging. Fortunately, the two I chose, Apache Axis and JAX-RPC, have classes that share many similar methods, and they create objects that are very compatible. Many of these objects, such as qualified names (Qnames), are largely portable between APIs, so one can choose to use pieces of each library where it is useful to do so. The Axis library is fairly large, including the axis.jar, commons-discovery.jar, commons-logging.jar, Jaxrpc.jar, log4j-1.2.8.jar, and saaj.jar.

The Axis' tcpmonitor utility is one very strong reason to use the Axis API instead of JAX-RPC. Since I likely would be using the tcpmonitor utility fairly frequently, I decided to wrap it up in a jar file that I could call from the command line. I unzipped the Apache Axis toolkit into a suitable location and altered the package declaration to allow compilation in the current directory. Next, I compiled it and placed the necessary files in a single jar file. This software came in handy for monitoring other TCP-based traffic (see Sidebar 1. Compiling and Packaging the "tcpmon" Utility).

The second reason to download the Apache Axis toolkit is the Apache Axis WSDL2Java emitter, a utility that can read the server side Web services deployment descriptor and generate JavaBeans-compliant "stubs", which serve as containers for the deserialized SOAP objects (see Sidebar 2. Generating Java "Stubs").



A final reason to opt for Apache Axis over JAX-RPC is that interfacing with the Axis BeanSerializer (which allows unmarshalling of complex data structures) is easier. So much so in fact that several Java gurus a the University where I work had no luck deserializing the SOAP structures when they used a purely JAX-RPC-based approach. The Apache Axis classes simply worked as we expected.

Initiating a Connection
Since this was my first experience working with the SOAP protocol, I started out with some trivial applications that merely established a connection and displayed intermediate results to standard output.

The documentation typically discussed deploying both a client and a server concurrently, so it was not directly applicable to my situation. I was attempting to connect to a preexisting server, and I had only the following resources available:

  • The documentation that I had regarding the procedure calls
  • Traffic the tcpmonitor utility intercepted
  • Some example perl code
  • Reference material I found on the Web

Since the connection uses standard HTTP and does not use an encrypted channel, some precautions are necessary to avoid sending an unencrypted password over the network. The client first requests a challenge string from the server. This string is then used to encrypt the password. The resulting encrypted password is then sent to the server to validate the client. So the first step in establishing that this service is available is to request a challenge string (see Listing 1. Challenge.java).

Retrieving The Data
After developing the initial code to exchange handshakes and establish a session, I had to actually extract account information from the server. Up to this point, the data returned consisted of simple types such as strings and integers, but the listing of user projects (which is returned by the getProjectStruct() remote method) returns in a more complex structure. At this point, I faced the process of converting the SOAP data structures into an equivalent Java class (not much more than a data structure with get/set methods). This process is known as data unmarshalling or deserialization.

Most of the documentation on unmarshalling SOAP assumed I had ready access to a client-side Web services deployment descriptor (WSDD). Unfortunately, I did not, but I did have access to the API reference. The server-side WSDD and the Axis library provided the missing pieces that I could not find in the JAX library, the BeanSerializerFactory() and the BeanDeSerializerFactory() methods. These methods register deserializers with objects of class TypeMapping, all within the connect() method in the GT_SOAPConnection class.



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