Java Driven Ian Moore's Thunk Dump

The Problem:

Here’s a question I’ve wrestled with:

“Is a browser based web application suitable for back office data capture?”

The answer I believe is a resounding NO! So why do we keep building browser based web applications for our users. I think, if we strip away all the rhetoric, the truth is simply: “because we know how”.

Now before you say: “but wait you’re oversimplifying”, let me assure you I have deep scars from the days of client-server. I remember how much time we spent solving the issues we had with software distribution.

So what is the solution? Do we even have a solution beyond trying to make our web apps behave more like desktop apps with AJAX and reams of Javascript. What about something like Flex ⁱ, Silverlight ⁱⁱ, or the new kid on the block JavaFX ⁱⁱⁱ? While these are all contenders, I believe that true RIA goes one step further.

Before I describe it, I would like to mention that we have successfully implemented this solution and it’s been in production for over a year. In the time it took us to design and build this application I’ve become more and more convinced that this is the way to go.

The Solution:

I can summarize the solution in three words: “The Netbeans Platform”. Actually, twenty one words are probably better: “Swing modules on the Netbeans Platform talking Web Services to JEE Services running on a standard Java Enterprise Application Server Cluster”.

I can almost hear flutter as the red flags go up…

Before I get to the nuts and bolts, let me state the obvious. Browser based apps do not negate the need for software distribution. That’s because the browser itself is desktop software. In fact I’ve personally experienced the pain of having dozens of users update their browsers via MS update only to discover that the Javascript in our web app no longer functions correctly. It is true to say that browsers don’t need to be updated as frequently as the business apps we put on top of them, and many companies have software that help them manage the distribution of desktop applications (like the browser and office products). I know it sounds like I’m angling for a client-server solution but I’m not really. I’m only trying to point out that we’re not living in a panacea.

First let me address the most obvious concern. The Netbeans Platform runs as a desktop application. The platform itself and and business modules written on top of it must therefore be distributed to the desktop. This is not nearly as bad as it sounds. Let me explain.

The Netbeans Platform has a built in update manager. This means that the business modules running on the platform can be automatically updated, without user involvement. Start the application and it updates itself seamlessly and painlessly. It’s just like a browser updating it’s own cache with a new version of a Javascript library. Updates are pulled via HTTP(S), so there are no compromises from a network security standpoint, and no firewall configuration changes are required.

It’s worth taking a moment to talk about the Netbeans Platform plug-in architecture. It allows the definition of discreet modules which add new business functionality or extend existing business functionality. The Netbeans Platform Update Manager only pulls updated modules. This allows you to only update the parts of the application that had changed, enabling easy management of very large and complex applications. In addition, modules can be installed on demand, so if a module is not required for a particular user, it is not installed for that user. All of this capability exists within the Netbeans Platform, and it’s solid and reliable.

The Java VM and the core components of the Netbeans Platform do not change very often and when they do the change must be managed in a way that is very similar to a browser upgrade. In a large scale production environment with many thousands of users, an upgrade like this will be staggered, with batches of users moving over to the new version while the other users keep using the old version. This staggered update approach is made possible because the same server side business logic serves both sets of users, making it possible to have both the old version and the new version continue to function in tandem while the update is rolled out. The Netbeans Platform maintains backward compatibility so that business modules written for a previous version will continue to function in the new version. The trick here is not to roll out business modules that depend on functionality introduced in the new JVM or Netbeans Platform versions until the upgrade is complete. This is exactly like not using new Javascript features until your browser upgrade has been rolled out.

Again, larger organizations will have a software distribution management solution that can be tasked for this purpose. For our smaller installation we created a Java Web Start installer that served our purposes perfectly. I should point out that we only had to do this once in 12 months. Also, bare in mind that we were releasing updates to the business functionality weekly via the Netbeans Platform Update features and we didn’t encounter any problems either before or after the platform upgrade. (Since we did that there have been several advancements in the area of update management in JDK 1.6_10 and later. These can be employed to further reduce the impact and frequency of these types of updates).

Okay, you say. That all sounds great, but doesn’t having a desktop application blur the architectural boundaries and complicate the solution as an end result?

The answer is: “Not if you don’t want it to”. Our approach was simple. We wanted to design an intuitive and functionally rich user interface without sacrificing the simplicity of our architecture. To achieve that we built only the UI on the Netbeans Platform. Things like courtesy validation etc, that would have been coded in Javascript for a browser solution were now coded in Java. Interactions between screen elements could also be coded in Java. No more Javascript. No more browser problems, it was magical.

I should also mention that Netbeans’ Swing GUI builder (Matisse) is amazing. We built our forms in Matisse in a fraction of the time it would have taken to build them in JSP/JSF etc.

So how did we manage transactions? How did we get this to all fit together and still behave much like a web application?

Our Netbeans Platform UI made it possible for us to organize and present data to our users in a number of different and intuitive ways. Each active UI component would request it’s data asynchronously from the JEE Server via a Web Service call. In this way our application behaved (from a server standpoint) in a similar fashion to a browser page with frames.

When it came to updating data we kept it simple. When the user wanted to update data they would select the item to update, enter their changes into the Swing GUI form and click ’save’. The end result from a server transaction standpoint was almost identical to submitting a browser form. The data in the form is packaged as XML and sent via HTTPS to the JEE Application Server. The message is processed via a Session Bean, exactly like it would have been if the request had come from the browser. Transactions, validations, optimistic locking etc work exactly the same way they would for a browser app with one exception: The data is sent back to the client via XML instead of being converted into HTML in a JSP/JSF page. We used Metro (JAX-WS/JAXB) for our Web Services and I must say the plumbing is all highly automated. Simple annotations were all that was required for us to turn our session beans into web services end-points.

What about performance? People tell me they’ve heard that Web Services are slow because of the conversion to and from XML. Personally I don’t think it’s any slower than a browser based web app. Let me explain why: To present data to a user in a traditional web application, the data must first be translated into HTML. This typically happens in a JSP page, or similar markup style template. The resulting HTML is sent over the network, and must then be converted by the browser into the page the user ultimately sees. Even assuming the perfect case where all of the images, style-sheets etc are cached, that’s still a lot more data going down the wire than the XML formatted raw data. Also, the conversion to and from XML is not really any slower than processing a JSP and rendering HTML. I don’t have metrics to confirm this except to say that we saw better that expected throughput on our servers. Also, since the stylistic presentation is part of the client software, there is no need to send style sheets and images over the wire.

The bottom line is that this architecture works. It really does. We were able to provide rich and intuitive user interface that greatly improved the situational awareness of out users which improved their decision making and productivity. I was skeptical myself at first, but as I began to see how easily we were able to clear the hurdles and how things that would have been challenging (to say the least) with AJAX were a complete non-issue with Swing and Netbeans Platform, I realized how powerful this architecture was. I would highly recommend this approach to anyone embarking on a back or front office business application development project. And here is the kicker. If you’ve developed a JEE (or J2EE) browser based business application that is in production (or even still in development), you can augment your capability but providing a Netbeans Platform Rich client desktop to the users that need it the most without changing your back-end architecture. You can re-use your back-end logic with minimal refactoring to service both your browser based app and your Netbeans Platform Rich Client Desktop features.

Last but by no means least…

It’s all Java!

I can’t stress this point enough. On a project I was involved with recently we were using another RIA technology for the front end. The biggest problem we have with that was finding good developers. We already had enough Java developers, but most were reticent to learn the new front end scripting language and so we had to hire folks with the necessary skills. Most of those new developers did not know Java and so we ended up juggling resources like some circus clown. It it so much easier if it’s all Java. Developers still have specialties, but they are eager to learn and managing a single development pool is much easier and more cost effective.

Food for thought?

Let me know what you think. I’d be happy to hear your experiences with the Netbeans Platform (or other platforms), both good and bad.