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 3

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 >

Leveraging JNLP
At first blush, JNLP deployment of jar files may seem as simple as repackaging the working program, writing a JNLP deployment file (not the same as a WSDD), and dropping the entire package on a friendly Web server. In actuality, it was not that easy. Because JNLP-deployed programs may not have access to standard output, all I/O must be done via the GUI. Furthermore, the interpretation rules for CLASSPATH values were not always obvious. It may be necessary to edit the JNLP file to either reference the necessary support libraries or unpack these libraries and re-roll them up into the deployed Java archive. The simple application that I wrote used standard output and relied on six other jar files.

Creating a Deployable Jar File
The JNLP file can include references to the associated Java archives needed to run the deployable applet. However, it was easier for me to include all the necessary classes in a single archive. In order to do that, I needed to extract all the required Apache Axis libraries into the base directory of a Java archive that contains the necessary libraries.

Finally, whoever deploys the jar file must take steps to ensure that the archive is signed. (see Sidebar 3. Signing Java Archives)



Deploying the Resulting Jar File
A deployable jar file can be placed on a Web server almost like any other file. The complication is that any Web page that launches this file cannot do so directly. The Web page instead references a JNLP file, which contains details such as security settings and necessary libraries to support the application. So any deployable jar file must be launched by an associated JNLP file.

I also needed to edit the MIME configuration for Apache so that it sent the correct application type to the browser, which would then in turn pass the JNLP file to a client-side JVM (a Java Web Start application launcher). For the Apache Web server, I needed to add the following directive to the /etc/mime.types file, then restart or reload Apache:

application/x-java-jnlp-file jnlp

Other Web servers differ in this configuration detail. If your browser does not receive the correct application type, it will either attempt to download the JNLP file or provide you with an XML parse error.

Bumps in the Road
Deploying a JNLP-enabled application presented an entirely new set of problems, most obvious to me was the lack of STDOUT and STDERR for debugging. I am considering just wrapping all future JNLP-based applications in a main frame with some sort of optional "console", which could be used to redirect display and debugging messages. JNLP directives could be used to toggle this on and off as necessary.

Lastly, I developed this application using Java 1.4.2, which has been superseded by version 1.5. So I should upgrade my compiler and test everything using the newest version of Java—as should you.

JNLP and SOAP: A Natural Mix
As is typical with learning a new language, class library, or network communications protocol, the process can alternate between being totally fascinating and maddeningly frustrating. JNLP deployment of SOAP applications is perhaps an ideal way to become familiar with other ancillary technologies such as XML, digital signatures, and thick-client deployment via an intranet. Developing centrally deployed (and automatically updated) client applications allows the programmer to add features without orphaning users who neglect to check for newer versions. At the same time, leveraging the cross-platform features of SOAP provides a greater deal of freedom in deploying application servers. Combining these two technologies seems like a natural mix.



Allan Peda is a programmer at the Rockefeller University working on various aspects of database management and development. He has a BA in biochemistry, an MS in Civil engineering, and is presently pursuing an MS in Management and Systems at NYU.
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