Juggling with DLLs, WebStart and Maven

Recently we were asked to implement a Drag & Drop mechanism between Microsoft Outlook and a Java based internet application. This necessitated our Java server having to communicate with COM objects on the client side. How do you do that?

The good thing is that our application was built using UltraLightClient, so we had java on both the server and on the client side. And after some thinking, the steps seemed pretty clear, even if a tiny bit of juggling would be required. However, the juggle almost turned into a struggle when we encountered some unexpected pitfalls.

In this blog I will give a quick sketch of our solution and point out some of the traps to be aware of.

Step 1: Talking COM using JACOB

In order to communicate with Microsoft programs from Java you need a Java COM Bridge.
We were using JACOB and it was surprisingly easy to extract Outlook mails into Java objects.

The idea:
The following method extracts the selected outlook mails to a directory and returns the list of created files:

The trap:
Using the email subject as a file name is practical, but it can contain many weird characters which may not be supported when the files are created. We found out that JACOB has problems creating files containing even characters like “:” and “,”. Furthermore, no exception is thrown, although the file fails to be created completely.

The solution:
Replace potentially dangerous characters with something neutral using regular expressions:

[[code]]czoxOTU6XCINCnB1YmxpYyBTdHJpbmcgZ2V0VmFsaWRGaWxlTmFtZShTdHJpbmcgcmF3U3RyaW5nKSB7DQogICAgUGF0dGVybiBpbnZ7WyYqJl19YWxpZENoYXJhY3RlcnMgPSBQYXR0ZXJuLmNvbXBpbGUoXCJbXkEtWmEtejAtOV8ge30rIV1cIik7DQogICAgcmV0dXJuIGludmFsaWRDe1smKiZdfWhhcmFjdGVycy5tYXRjaGVyKHJhd1N0cmluZykucmVwbGFjZUFsbChcIiBcIik7DQp9DQpcIjt7WyYqJl19[[/code]]

To be on the safe side we were using a whitelist approach. We treat everything as invalid except for characters which are listed after the “^” character.

Step 2: Shipping a DLL with Webstart

JACOB can talk to Outlook because it comes with a DLL which has to be present in the classpath. This means we either have to ensure that all our users have this library installed (yikes!) or we ship it together with the application client using Java Webstart.

The idea:
We include the DLL in the jar file and sign it with a valid certificate. Then it can be referenced from the JNLP file that launches your web application:

[[code]]czoxNjc6XCINClsuLi5dDQogICAgPCEtLSBBdHRlbnRpb246IFRoaXMgZG9lcyBub3Qgd29yayEhISAtLT4NCiAgICA8cmVzb3VyY2V7WyYqJl19cyBvcz1cIldpbmRvd3NcIj4NCiAgICAgICAgPG5hdGl2ZWxpYiBocmVmPVwibXktZGxsLmphclwiIGRvd25sb2FkPVwibGF6eVwiLz4NCiAgIHtbJiomXX0gPC9yZXNvdXJjZXM+DQpbLi4uXQ0KXCI7e1smKiZdfQ==[[/code]]

The trap:
We were using the optional parameter download=”lazy” to ensure that the library is only downloaded when it is really needed. The result was that it never got loaded at all(!) because we did not specify to which “part” the library belongs. This is another optional parameter which turns mandatory in combination with download=”lazy”.
Unfortunately this little detail is not too well documented. The only hint found was this one (in german). It took me quite some time to find this critical information.

The solution:
Since the jar containing our DLL is really small we chose to use download=”eager” (which is the default anyway) instead of defining “parts” in our JNLP.

[[code]]czoxNTE6XCINClsuLi5dDQogICAgPCEtLSBUaGlzIG9uZSBpcyBlYXNpZXIgYW5kIGl0IHdvcmtzISAtLT4NCiAgICA8cmVzb3VyY2V7WyYqJl19cyBvcz1cIldpbmRvd3NcIj4NCiAgICAgICAgPG5hdGl2ZWxpYiBocmVmPVwibXktZGxsLmphclwiLz4NCiAgICA8L3Jlc291cmNlcz4NClt7WyYqJl19Li4uXQ0KXCI7e1smKiZdfQ==[[/code]]

Step 3: Using native lib references with the webstart-maven-plugin

We already were using Maven as a build system and our client distribution is generated with the webstart-maven-plugin as follows:
- We use a separate module with packaging type “pom” for the generation of the webstart client. Of course, this module is part of the multi module build for our application.
- We provide a template for the JNLP file containing a parameter “$dependencies” which will be replaced by a list of the dependencies of the current module
- At build time the dependencies will be signed and put into a zip file together with the JNLP file.
- The zip file can be extracted to a java webstart server or, in our case, into a war file that will be deployed on a server.

The idea:
Since JACOB is available via Maven Central integration seemed pretty easy. We only have to generate the correct reference to the native library.

The trap:
Unfortunately the current version of the webstart-maven-plugin (1.0-alpha-2) does not support native libs (open issue). So we will need a workaround that wraps the jacob.dll into a jar file and generates the nativelib reference in our JNLP.

The solution:
Perform the following steps:
- Change the packaging type for the module from “pom” to “jar”.
- Configure the pom.xml to copy jacob.dll from the maven repository into the build directory of the module using the maven-dependency-plugin
- Add the nativelib reference to the velocity template using the build artifact of the current module as a reference.

[[code]]czoyNjA6XCINClsuLi5dDQogICAgPHJlc291cmNlcz4NCiAgICAgICAgPGoyc2UgdmVyc2lvbj1cIjEuNStcIiBpbml0aWFsLWhlYXAtc3tbJiomXX1pemU9XCIyNTZNXCIgbWF4LWhlYXAtc2l6ZT1cIjUxMk1cIi8+DQogICAgICAgICRkZXBlbmRlbmNpZXMNCiAgICA8L3Jlc291cmNlcz4NCntbJiomXX0gICAgPHJlc291cmNlcyBvcz1cIldpbmRvd3NcIj4NCiAgICAgICAgPG5hdGl2ZWxpYiBocmVmPVwiJHtwcm9qZWN0LmJ1aWxkLmZpbmFse1smKiZdfU5hbWV9LmphclwiLz4NCiAgICA8L3Jlc291cmNlcz4NClsuLi5dDQpcIjt7WyYqJl19[[/code]]

Summary:

After successfully having avoided the traps (okay: by stepping into them and finding a way out again) we got an application with a pretty cool feature integrated seamlessly in our build process. Nice!

The future belongs to Rich Internet Applications (RIA) – they are increasingly replacing the classical desktop application. And it is no wonder, as this latest generation of web applications offers a totally new kind of interactivity. Furthermore, RIAs spare your budget thanks to their operating system independence and the fact that they can be used without installation. According to the market research organization Forrester Research, RIA technology will be deployed in around 60% of all software development projects in the coming years.

The disadvantage of most of today’s RIA frameworks is that they were developed for the optimization of web sites. They rapidly reach their limits, therefore, with complex business applications. Canoo Engineering’s Canoo RIA Suite with its modular design provides a remedy. It’s heart is ULC (UltraLightClient), a proven and stable component for the development of RIAs – optimized for the performance requirements of business applications. Thanks to the 100% java-based homogeneous programming model, ULC reduces the complexity of RIA projects to a minimum. RIAs developed with ULC score highly due to their low development and maintenance costs, and are more than a match for classical desktop applications in user-friendliness, functionality, attractiveness, robustness and performance.

Since March 31, 2010, ULC Core is available as a Beta Release. The Canoo Ria Suite will be released officially just before Pentecost 2010. The advantages at a Glance:

• Up to 50% reductions in development costs
• Puts business functionality on to the web without quality losses
• Lower operational costs thanks to server side maintenance and standardized technology
• Maximum security thanks to standard conformity
• Straightforward and rapid development due to uniform Java basis
• Robust and scalable architecture
• No longer time-consuming client-side deployment
• Enables highly interactive and user friendly interfaces
• No browser adaptation required
• Optimal user productivity due to rapid response times
• Lower project risk thanks to well engineered, tried and tested technology
• Impressive prototypes in minimal time

“We switched to ULC in the middle of a large software project, as we were not able to implement all the requirements with the technology we were using at the time. ULC then enabled us to at least double our productivity, in turn allowing the project to be completed on time.”

Greg Hutchinson, Principal Developer of a large Canadian financial institution

The Apple iPhone, just like its bigger brother (the iPad), does not exactly shine with its universality: In the end, the technical options and the contents that may be used are determined by the parent company.

However, it is precisely this limitation in the user and developer flexibility, in addition to the purist and inherently coherent design of the user interface that are the secret of its universal success. The user experiences a successful reduction in complexity from app to app within a homogenous user interface environment, in which he quickly finds his way around. The problem of information transport, according to media expert Neil Postman, has long been solved. Now it is about developing the right selection techniques in order to come to terms with this flood of information.

Successful complexity reduction

Precisely this demand is fulfilled by the in-house engineers at Apple, as well as the developers of successful programs that run on the iPhone. Now however, these inventers often are not exactly world-beaters when it comes to experience in UI design or architecture development. Rather they place themselves intuitively in the shoes of the users and ask themselves what information they would like to call up on their iPhone themselves. And Apple supports this implementation via an SDK that delivers many graphic effects and interface components out of the box. This intentional simplification of options creates a world which eases the navigation through this flood of information to such a degree that most users happily put up with any such limitations.

Levelling the fastest routes

What can we learn now from the iPhone phenomenon for the development of Rich Internet Applications? In production systems it is less crucial to push the limits of technical feasibility or to place emphasis on the maximum user flexibility. What counts instead is to smooth the most rapid route to the required information and functions for the users, without them having the need to deal with the intricacies of program structure. To fulfil these needs the developers need to put themselves in the users’ shoes, which is easier in the case of greatly restricted iPhone apps than with complicated web applications that quite often cover the scope of entire departments.

In view of these over-complications it seems tempting in the initial phase of a project not to pose too many questions to the end users (or indeed one’s own intuition), but rather to proceed in the hope that people will get used to the technically more familiar structures. These are, however, shortcuts that can come with acrimonious paybacks at a later date.

Tools that help those in charge to see things from the users’ point of view (e.g. paper prototyping) may initially appear laborious and, due to the lack of “hard” results, unnecessary. But rather than definitive guide-rails, this phase is more concerned with developing a feeling how the users’ workflows could be integrated into the future application, and to identify which paths in the current IT environment are often or only seldom trodden, so as to provide orientation for the subsequent development process.

The goal is therefore to pick out the basic limitations and requirements for simplification right at the start of a project, so as to attain similar complexity reductions in the context of productive systems such as some successful iPhone apps demonstrate.

We are happy to announce the second RIA forum which will take place in Darmstadt (close to Frankfurt), 23rd of April 2010! This time, with Canoo Engineering AG as premium sponsor, four well known speakers will talk about the advantages and disadvantages of four different ways to create effective user interfaces (especially in business contexts).

Instead of giving details here I recommend to visit the forum page directly: http://www.riaforum.com (in German). Please be aware that we can only provide entrance to a limited audience, so if you want to join, make sure you sign up quickly.

Watch an interesting interview (in German) with Dierk König about the actual language diversity in the Java community — Groovy, Scala, Clojure, JRuby and all the rest of them! If you are interested in this topic, we also recommend to take a look on the schedule of the Java Language Days 2010 (moderated by Dierk König and Markus Völter (itemis).