In practice, before developing a real application, you must implement a "development infrastructure", i.e., a software layer used by the application that supplies a set of rich graphics components, more advanced than those provided by the Swing toolkit, often too poor to use directly in rich client applications, such as enterprise applications. In other non-Java development platforms, like Visual Basic, Delphi or .NET, a collection of rich components is provided, more powerful than Swing provides.

The need for a set of "advanced" graphics components is not the only issue: a "data-binding" mechanism is also desirable. Moreover, three-tier client/server applications also need to interconnect the presentation layer with the business logic layer - two layers that reside at distinct sites - to send service requests and get the responses (e.g., data to view in the front end); so a "data-retrieval" mechanism is also required.

Hence several software layers can be identified in rich client applications.

A Data Binding Mechanism
A data binding mechanism links and synchronizes the view component (graphics control) and the data model (i.e., the data container) by optionally executing a validation task when editing data in the input control or when saving it.

In recent years the trend has been to realize the data model by using POJOs (a.k.a Plain Old Java Objects) by storing data using simple JavaBeans, whose attributes contain single data; this way data showed in input controls added to a form can be stored using a JavaBean (that eventually contains other inner JavaBeans), a list of rows to show in a grid can be stored in a list of JavaBeans, one for each row, a tree that shows nodes can use a data model composed of a tree of JavaBeans, one for each node.

This data model representation goes well with the operations of an ORM tool that maps database tables and relations to relations between objects, represented by JavaBeans, or by using a data mapper, a bit simpler than an ORM tool, since it maps fields of a SQL select to the attributes of a JavaBean.

A data-binding mechanism can be realized in one of two ways: first, an ad hoc component has to provide the data binding to external input controls; this data-binding component needs code written for each input control to bind in order to register it in the data-binding component, usually by specifying an attribute of the data model (e.g., POJO) that contains data to synchronize to input control; the same data-binding component can be used to supply some other services, such as data validation (for instance, in the case of a numerical input field, a possible data-validation policy is to check if the edited data is a number; other data validations are value-not-null checking, data length not greater than a specified length, etc.).

The main advantage of this first solution is that it can be applied with very simple input controls, such as those provided by the Swing toolkit (that don't support data validations such as data length, data required, data-type checking, etc.) by enhancing them; anyway this solution could require writing a lot of code to use the data-binding component, especially for data validations to apply to input controls. This code cannot be fully automated by the IDE. This solution has been used inside the Eclipse RCP/JFace platform for rich-client development not based on Swing and in some open source libraries for Swing, such as JDNC, Beans Binding (JSR-295), and Bindings - JGoodies data-binding framework.

The second solution is to embed a data-binding mechanism directly in each input control, this way a programmer only has to set some properties available in input control, using, for instance, the UI designer of the IDE to link it to the data model. This approach requires that the input controls be more advanced, since they have to implement the data-binding mechanism inside them and eventually data validation too (numeric only, type checking, mandatory, data length, etc.) or data conversion/transformation (for instance, an Integer type object to BigDecimal type object or text trimming or text padding, text to uppercase, etc.). The latter solution can easily be included in the UI designer of a Java IDE, if the advanced controls comply with JavaBeans specifications, by reducing the amount of code to write manually, since code can be automatically generated by the UI designer without expecting any special feature from the IDE except JavaBeans spec support. This solution is used in several non-Java development environments such as Visual Basic, Delphi, and Visual Studio .NET and can be more effective than the first solution, since it requires less code written by hand and so is less error-prone and more productive.

A Data Retrieval Mechanism
A data retrieval mechanism connects the data model used on the presentation layer directly or remotely with the business logic layer. This mechanism is supposed to internally invoke the services provided by the business logic; in the case of three-tier client/server applications, the data retrieval mechanism has to invoke the remote services available in the server tier, using some kind of communication protocol, such as HTTP(s). In the case of two-tier client/server applications, the services provided by the business logic can be directly invoked using local method calls.

Another goal of this software layer is to provide a uniform communication interface used to retrieve data, i.e., requests and responses can be normalized to a well-defined set of formats: a retrieval request of a list of rows to show within a grid component should also include information about which block of data to retrieve (in the case of a grid that loads a block of data per time), filtering and sorting optional conditions, and other data required to retrieve the list of rows correctly. The response should also support several scenarios: hold a list of data (such as a list of JavaBeans) - or a single JavaBean or send back an error message - managed directly by the data-retrieval mechanism or forwarded to the data-binding mechanism or sent directly to interested input control, etc.

Another conceivable task for this layer is to support a server-side user session when available/requested to make the client tier compatible with the conversational state of the server tier and user recognition in all subsequent requests.

Advanced Graphic Components
A set of advanced graphics components avoids or reduces the writing of low-level and repetitive code and automates code generation (data validation, events management, input control properties setting, etc), preferably using the UI designer of the IDE adopted.

• Developing Rich Client Applications Using Swing - II