If these applications use the standard Internet protocol (HTTP) and the presentation layer is launched starting from some Java client-side technology, such as the browser that executes an applet or Java Web Start, then the resulting software solution could be classified as a Rich Internet Application (RIA), since it provides a rich front end and functionalities that are typical of more traditional desktop applications but, unlike these ones, it can be remotely accessed from the browser.

Three-layered client/server applications can be realized by combining several technologies available in the J2EE platform:

• Swing for the presentation, HTTP(s) as the communication protocol between the client and server layers, servlet for the server layer, and JDBC for database access. The proposed server-side solution may result in complexities and long development time when programming directly with JDBC.
• Swing for the presentation, HTTP(s) as the communication protocol between the client and server layers, servlet for the server layer, and finally an ORM/data mapper tool for database access. The adoption of an ORM/data mapper tool allows abstracting the database management and can simplify the server-side development phase. There are many ORM tools, such as Hibernate, Oracle TopLink, and Apache Cayenne, and data mappers such as iBatis. They differ in complexity on mapping definitions and in the strength of the adopted query language.
• Swing for the presentation, HTTP(s) as communication protocol between the client and server layers, the Spring framework as the foundation for the server layer, and optionally an ORM/data mapper tool for database access. Spring framework adoption can simplify some server-side issues, such as transaction management (for instance, by using Aspect Oriented Programming to identify a set of classes and events associated with classes and methods invocation to mark transactions over more classes/methods), encouraging decoupling of server layers using dependency injection; optionally Spring can supply a base solution for wrapping the JDBC API to map SQL queries to objects.
• Swing for the presentation, HTTP(s) as the communication protocol between the client and server layers, and Servlet + EJB for the server layer. EJB 1.x/2.x appears to be rather complex. EJB 3.0 introduces a significant simplification overwriting Enterprise JavaBeans and their file descriptors thanks to J2EE 1.5 and annotations adoption.
• Swing for the presentation, RMI as the communication protocol between the client and server layers, and EJB for the server layer. The adoption of RMI as the communication protocol seems to be more suitable for intranet environments rather than for Internet-based applications.
• Swing for the presentation, SOAP as the communication protocol between the client and server layers, and Web Services for the server layer. Evaluate the adoption of Web Services with caution: they represent a good solution when interconnecting heterogeneous systems, but if excellent response time, minimizing transmitted data, and security are issues of vital importance, then maybe Web Services might not be ideal.

All these architectural solutions use Swing as the client-side technology for developing the user interface. For completeness, there are also other Java technologies that can be used to realize a rich user interface based on JSF or JSP and combinations of JavaScript/DHTML/AJAX. However, these solutions don't typically offer all the client-side features provided by desktop applications, such as local file system access (e.g., file system navigation/search and local file writing) or local peripheral access (printer, scanner, bar code reader, etc.) or the interconnection between the front end and servers that require communication protocols different from HTTP (e.g., e-mail server and legacy systems).

Another valid solution for rich client development is the Eclipse RCP based on the SWT toolkit and not included in the core Java SE APIs.

All these solutions are not dealt with in this article, which is focused on evaluating technologies for rich client development and strictly concerned with Java Standard Edition (J2SE), specifically with Swing.

With respect to business logic development and the database access layer, many alternative solutions have been reported above: JDBC, dependency injection, AOP, transactions management based on Spring, transactions management based on EJB, EJB 1.x/2.x/3.0, entity persistence based on JPA, ORM and data mapper adoption.

On the whole, it is difficult to establish which architectural solution should be assessed as the optimal choice; three-layered client/server applications should not always be regarded as better than two-layered client/server applications, instead the architectural choice should be made according to your particular conditions: software architecture and the technologies required influence key issues, such as development time, software release data, required skills and the complexities of the technologies adopted, the execution environment (LAN versus Internet), the strength of the architectural solution, scalability, and available budget.

Developing Rich Client Applications Using Swing:
Pros and Cons
The Swing toolkit includes many base graphics components and some complex components as well, such as JTable, JTree, JComboBox, and JList. The design of these complex components lead to splitting the presentation (View) from the data storing and management (Model) and events and user interaction handling (Controller), according to the MVC paradigm, that improves components decoupling and encourages components reuse (especially for View components).

Swing components have been created by keeping to JavaBeans specifications. These specifications create a sort of contract between the graphics component and the user interface designer (UI designer), i.e., the visual editor that can view and graphically configure the graphics component. Thanks to JavaBeans specifications the visual editor can interpret Java instructions related to the component written in a source file and render the component in it; moreover, a programmer can directly use the visual editor to set component properties and, as a consequence, the editor generates Java instructions according to properties set. Hence JavaBeans specifications allow the same visual editing of graphics components available in other non-Java IDEs too, such as Visual Basic, Delphi, or Visual Studio .NET.

JavaBeans specifications represent the strength of Swing development because (1) an IDE can use them to draw forms and (2) new graphics components can be developed that the UI designer of the IDE recognizes, provided the new components are faithful to JavaBeans specifications.

Other advantages to using Swing for the presentation side are the ability to download and start client-side applications through the browser, as long as client-side applications are based on a Java applet, and the ability to download and start client-side applications through Java Web Start. These devices solve the problem of applicative updates to apply on client-side machines: a client-side application is never really installed on a client-side machine. Instead the last version is downloaded and cached locally.

Developing rich front ends using Swing pose some issues too. A rich front end requires a collection of rich components, but the Swing toolkit only provides a set of base components and has been little changed and not improved in recent releases of Java, so using only Swing for rich client development is not the best solution. Whoever uses Swing has to deal with low-level programming issues, such as table model definition; tree model definition; creation of renderers and editors for table cells; creation of renderers for tree nodes; ad hoc event handling for data validation; to realize advanced "rich" components, such as numeric input field, currency input field, and calendar.

• Developing Rich Client Applications Using Swing - II