The Third Option besides AJAX and Flex (Part 3 of 3)
This is part 3 of 3 blog posts discussing the article “How to Choose an RIA Path: AJAX or Adobe?” by Jeffrey Hammond. Read part 1 and part 2.
Java is a third option to breakdown the barriers RIA faces in corporate environments.
In this final post, let’s turn our attention to the first point I listed in my comments on Jeffrey Hammond’s article (see part 1):
AJAX and Flex are not the only options for RIA. There is a third one to consider: Java (see for example Eclipse RCP, a rich fat client technology, or UltraLightClient, a Swing-based rich thin client technology).
Jeffrey identifies four barriers that prevent firms from introducing RIA (based on AJAX and Flex):
- Both are not easy to integrate into an enterprise environment.
- Both are in some way dependent on the client configuration (or a user’s willingness to change it). Although AJAX does not require any additional installation, JavaScript may be disabled and AJAX applications will not work. Adobe requires the Flash plug-in and users may not be willing to install or update it to for a RIA they find on the web.
- The ecosystem for both approaches is not mature.
- Both lack the support of extended development tools.
Reuse Existing Infrastructure
Java – on the other hand – has been in use as a server technology for Web applications for many years. The infrastructure to integrate applications into a corporate environment is available. This infrastructure is proven and there is a lot of experience on how to use it. As outlined in part 2, companies that operate HTML-based Web applications will not have to change the connection to data sources when migrating from these Web applications to Java-based rich thin clients.
Of course, a Java-based RIA requires a Java browser plug-in. Consequently, this barrier remains as high as before – at least for internet applications. But for applications with a limited user community, installation of a plug-in like the JRE or Flash is in many cases acceptable.
Java has a rich and mature ecosystem which has been evolving for more than ten years. A wide selection of proven commercial and non-commercial libraries, frameworks, and tools are available.
There are various extended tools supporting quality assurance such as testing tools, monitoring and measuring tools, as well as development and debugging tools. What is lacking is a comparable design and authoring tool support as offered by Adobe and third party vendors of Flash.
After having said this, I would refine Jeffrey’s recommendation regarding when to use AJAX and when to use Flex in the following way:
Jeffrey recommends using AJAX when time-to-market is critical and when frequent changes to an application are expected. I would add: Use AJAX if this application is published to the general internet at large and browser plug-ins are not tolerable. It is a good advice today to restrict AJAX to a minimum and to ensure that the application works even if JavaScript is disabled.
For large-scale user productivity applications, Jeffrey opts for Flex. I would add: yes, if besides functionality the visual appearance of the applications is critical, and as a result, advanced design and authoring tools are needed.
In all other cases, i.e., if I do not want to publish my application for casual internet users that are just passing by, and visual appearance would be nice, but functionality and integration into an enterprise information system is more important, then I would recommend using a Java rich thin client like UltraLightClient.
