In the previous Industry Insight, I looked at MVC frameworks. In this, the second last in this series, I will look at other frameworks and factors to consider when choosing a Java Web framework.
Other frameworks
The following frameworks cannot be easily classified into a particular category, but are still worth mentioning as part of a front-end investigation.
* Seam
Seam cannot really be classified because it is not simply a Web framework, but actually a full application stack, from persistence to process management to service and Web layers. It uses industry-standard technologies for each layer, making it an appealing choice when writing new applications from scratch:
Persistence: JPA/Hibernate
Process management: JBPM
Business logic and service layer: EJB 3.0
Web: JSF
An alternative to using a Rich Internet Application framework is to create a rich client, and deliver it with Web Start.
Andre van der Schyff is a senior developer at DVT.
The framework ties together and enhances each of these layers. For example, it provides various stateful contexts aside from simple request and session - state can be maintained over a business process or a "conversation" (identified by being started and ended explicitly). Users can also have different states in different workspaces. Furthermore, it provides advanced workflow and page flow functionality by using JBPM.
* Swing/Web Start
An alternative to using a Rich Internet Application framework is to create a rich client, and deliver it with Web Start. Of course, within the rich client world there are a number of frameworks to choose from. The advantage of using Swing or another rich client technology is that it enables offline processing and graphics capabilities. However, it is not without pitfalls, as the client requires the correct JVM, and the application itself must be distributed. Web Start helps with this, but it also caches jar files and is not perfect. The front end will also require a service layer with data transfer objects (DTOs), as a rich client cannot be bolted directly onto the domain layer. This requires some mechanism to translate between the domain and DTOs, which requires separate work and maintenance.
* Adobe Flex
Another option is Flex, which uses XML markup and ActionScript to produce a Flash-based thin client delivered using a browser. This is an appealing approach, since Flash is highly portable, and allows some state to be maintained on the front-end. Using Flash also allows developers to design rich, good-looking front-ends. However, it should be noted that although Flex is free, the tools required to develop optimally are commercial. Also, Flex does not use HTML at all, so fairly specialised design skills are required. Flex uses its own remoting mechanism similar to RMI, which developers may not be familiar with, but also provides innovative features such as a publish/subscribe messaging between the server and client, as well as data management services for managing data downloaded to the client.
* Grails
This framework borrows many of its ideas from the very popular Ruby on Rails framework. It is aimed at enabling very rapid application development through coding by convention, and is very different from the other frameworks discussed; in fact, it uses Groovy as its language rather than plain Java. This makes sense as Groovy is an interpreted language for the Java platform, so changes can be made without recompiling. Similar to Seam, Grails provides a full application stack.
Although developers would normally not be aware of it, it uses Hibernate for ORM and Spring for MVC in the background. On top of this, developers can create high-productivity applications by using dynamic tag libraries, dynamic class and instance methods (commonly needed methods available on all objects), scaffolding for CRUD operations and dynamic tag libraries, in conjunction with an interpreted language.
Due to its very different approach, one may run into difficulties integrating Grails with other frameworks, as well as resistance from developers. Until it has been proven for large-scale systems, it may be best used for very rapid development of smaller applications, or applications with more typical create/read/update/delete requirements.
In the next Industry Insight in this series, I'll consider the factors to bear in mind when choosing a Java Web framework.
* Andre van der Schyff is a senior developer at DVT.
Share