by Björn Müller
CaptainCasa moves from Swing to JavaFX for front-end infrastructure.
Published March 2013
: Java FX
CaptainCasa is an open community of midrange business application software vendors using and developing one common front-end infrastructure, the CaptainCasa Enterprise Client, for our business applications.
Business applications tend to be:
Companies using CaptainCasa Enterprise Client provide software solutions in the areas of finance, resource management, logistics, manufacturing, human resources, and administration, among others.
The CaptainCasa community was founded in 2007, at which point we decided to use a Swing-based implementation for our client. We are just moving over to JavaFX—and that is what this article is about.
In 2007 everyone told us, "You are stupid not to use Adobe Flex!" At developer conferences, the Adobe sessions were overcrowded. It took some time and one e-mail from Steve Jobs to end this fad.
One year ago, Google Web Toolkit was the craze. Now Google has told the world that it will concentrate on Dart as the new language for the dynamic Web. So the next fad is on its way...
Be careful with fads in the area of front ends: they just change too often.
Figure 1. Comparative lifecycles of Web UI fads and of large business applications.
Of course, managers always want to be on the fad side of life! "Everything must be HTML5!" How many times we've heard this clear and simple pronouncement, knowing that the person asserting it does not even know what HTML5 really is!
You should not avoid fads at all cost—on the contrary! You should embrace trends when and where it makes sense: you need HTML screens for a lot of scenarios, but you need native apps for other scenarios. So your architecture must be open enough to include any of these technologies in an efficient way.
But you must not decide on core aspects of your application architecture just by following today's latest craze. The lifecycle of your business application will definitely be longer than the lifecycle of today's hype. You won't have the budget to adapt the core screens of your application every five years, and you won't have enough customers left to be amazed about your business if you update core parts of your application frequently.
The situation is getting even worse today:
There should be a way out, with a framework that hides all the complexity or at least helps you manage it. To handle this complexity, these frameworks need to be complex in their own right.
There are many frameworks. Some are today's fad, some were yesterday's craze, and some will be tomorrow's hype—and many of them will disappear or stop being developed and supported.
What do you do if something does not work in your application's front end—for example, there is a bug that occurs only with Firefox but not with Internet Explorer, or vice versa? You'll have to be in very close contact with the framework guys. Your customer expects a solution, so you'd better deliver!
There are two options when it comes to implementing front ends:
Both approaches have proven to work and be efficient:
Be skeptical if you are told that using HTML5 is the only way to offer new functionality to end users. It's just not true: thousands of apps and millions of installations per day prove that there is an alternative!
Luckily, Java(FX) is moving in the right direction here, providing the possibility of deploying Java-based programs as self-contained bundles (let's call them Java apps). These Java apps run directly on the user's desktop, do not require separate installation of the Java runtime environment (JRE), and do not require that administrator privileges be set.
When it comes to the CaptainCasa community, then, the conclusion is this:
The typical screens for employees are complex: there is a lot of information that must be conveyed, many means of interaction (keyboard, mouse, right mouse button, shortcuts), close integration with the desktop environment (file system, third-party applications such as MS Office), and sometimes direct integration with peripherals (scanners, card readers, printers). These screens typically form the core of the application and are expected to have the same lifecycle as the whole application. The screens must run reliably in the customer's environment—with minimal dependence on the user's client system. For these screens, local installation of native client apps is optimal.
Then there are the screens for anonymous users, where zero installation is a must. Most of these screens are quite simple (but styled in a nice way, of course!). The lifecycle of these screens is usually much shorter than that of the core screens, because they are often designed for a certain usage scenario. Here it makes more sense to use HTML5. As you increase the complexity of the screens, you know what additional effort will be required to ensure browser compatibility and the like.
We believe that choosing the right framework for the right user interface category—instead of standardizing on one framework for all the application's screens—is essential. Standardizing on one framework for everything remains the ideal solution, but so far, such a solution has remained elusive. Therefore, a reasonable solution is to leverage the combined strength of the two frameworks.
Here is a typical question people ask about HTML5: "Are there any functional restrictions on using HTML5 as a front-end environment?" The answer that managers hope for is, "No, of course not," because using HTML5 for all screens would make things so much easier. But a more accurate answer would be, "(Nearly) everything can be done with HTML5." It's just a question of cost and efficiency.
Typical business application development groups are not very large. Many midsize companies have limited development resources and crave a simple, efficient approach to software development. This situation translates into the following requirements:
End users have increasing expectations: they want to see animations, transitions, and interactive graphics when and where it makes sense. Developers, on the other hand, are looking for development environments that hide the complexity of certain tasks such as creating UI controls or assembling them from existing ones.
Somehow all of this is possible with HTML5, but at what cost? Small development groups should think twice about whether using HTML5 is the most efficient strategy for managing large, multiyear projects or whether it makes sense to rely on a single framework that is very unlikely to encompass the lifecycle of an application. Couldn't going the "app way" be a more efficient approach to making your front ends work on a client site?
Our experience proves that implementing an employee desktop front end with native technology is a valid approach and that JavaFX is a good fit.
In short, we believe that JavaFX is the only native UI environment that provides all these features today.
We have been developing with JavaFX since mid-2012. Here is what we've found out:
Now that you know why we chose JavaFX as the UI technology environment for our employee screens, let's revisit the architectural context in which the JavaFX UI is used in the CaptainCasa enterprise client framework.
The essential question is this: How fat or thin is your client application?
To clear up any confusion about the terms fat client and thin client, read on.
A thick client is responsible for more than the UI; it also holds a significant amount of application logic. In technical terms, events and data input from the user interface are directly (pre)processed in application functions on the client side. From time to time, the client may communicate to a server, calling certain APIs, for instance, to pass data that was entered.
Figure 2. A thick client handles some application logic in addition to UI interaction.
Use cases in which a thick client makes sense are when
But a thick client also has some limitations:
Typically the thick client approach is valid for simple scenarios. For example, if you want to implement an e-mail client as a JavaFX application, there are only a few interfaces for reading and sending e-mails and the corresponding logic is quite clear.
The thick client approach is too complex when it comes to business applications with hundreds of screens. Just imagine the client of an SAP business application being implemented as a thick client.
An alternative is the thin client. In this type of architecture, the client is a pure rendering engine—receiving an abstract form, such as an XML description, from the server; rendering this form (via JavaFX components); and passing user input back to the server for processing at the correct time.
Figure 3. In a thin client architecture, abstract forms go from the server to the rendering engine and back to the server for processing.
In this scenario, the server is what builds the form (in XML) and processes user input. In terms of the interaction logic of an application, this means that the business processing of the form takes place on the server side. The client does not know any business semantics behind the form it renders: whether a form represents a purchase order or a vacation request, the client will know nothing about that.
The thin client architecture means that you need some infrastructure:
But if you have this infrastructure, the advantages are that:
The choice of the correct architecture is essential.
The thick approach enables you to finish the fastest: you just take JavaFX and get started. But it has limitations when it comes to more-complex scenarios.
The thin approach is suitable for business applications, which generally tend to be larger and more complex. For such applications, it both significantly increases the efficiency of development and decreases the cost of operation at runtime.
When you're going the thin way, you have the option of either developing a client framework on your own or using an existing infrastructure.
CaptainCasa is an existing thin client infrastructure that provides a Java-based client app on the client side and JSF-based processing on the server side.
"JavaFX with JSF": this may sound a bit strange at first, because JSF is known as an HTML infrastructure. But it is a Java EE server standard that, from its inception, was abstracted from the concrete HTML browser client—to support other rendering infrastructures as well. So it's a perfect fit!
JSF is a server-side interaction framework. Its basic processing is as follows:
You see, JSF is used just as usual, but now it is serving a JavaFX rendering client—rather than the browser, as in a default scenario. From a network perspective, there is no structural difference between a CaptainCasa JavaFX client and a normal browser, except that instead of HTML, now a certain XML is sent over the line.
We started developing the CaptainCasa Rich Enterprise client in 2007, using Swing, and we currently provide about 100 controls that can be added into forms. Today we're re-implementing our client in JavaFX.
Both implementations leverage an XML layout definition that was originally abstracted from Swing. As a consequence, the JavaFX client is using the same layout description as the Swing client and the clients are compatible with each other.
We view this as a key concept of the architecture:
In summary, the switch to a different rendering technology on the client side should not translate into any serious issues or require any reimplementation effort on the server side.
Figure 4 and Figure 5 illustrate the difference between rendering with a Swing-based client and a JavaFX-based client.
Figure 4. Rendering with a Swing-based client.
Figure 5. Rendering with a JavaFX-based client.
Figure 4 shows a specific page rendered with our Swing-based client, and the Figure 5 shows the result of rendering with the JavaFX-based client. Yes, there are differences in colors, edges, and the like, but they are due to the application of different screen styling. The behavior in both cases is actually the same.
Björn Müller—one of Europe's pioneers in the area of Rich Internet Clients—is the founder and CEO of CaptainCasa Gmbh, a community of German software companies focused on client frameworks for large, long-lived application systems.