While Struts and Tiles add a layer of complexity, overall they're an improvement over custom code since they replace custom MVC and Tiling frameworks with proven, tested, and well documented frameworks that are based on industry standards such as Java/JSP/XML. (We'll explore why frameworks are good in the next section.) However, there are still some serious consequences to using all these technologies:

1. You must have people trained in one or more (preferably more) of these technologies
2. Someone has to understand how each layer interacts with its neighboring layers
3. Each technology/framework will develop at its own pace - possibly introducing versioning and dependency issues with the other technologies

Savings # 2: Reduce the Number of Technologies Used in Development
So, it seems reasonable that by reducing the number of technologies used in an application, you'll simplify and probably speed up development (see Figure 2). One way to do this is to use Swing for the presentation layer. Swing provides the following benefits:

1. Extremely rich user interface
2. Excellent development and code management tools
3. Easily customizable and extendable
4. Many third-party components and libraries available
5. Reduces the number of technologies you must know to ONE
6. Easy management and distribution with Java Web Start

By using Swing instead of HTML, JSP, JSF, XML, and JavaScript, you've dramatically simplified your development effort. Code management becomes a breeze. The user interface is much richer and you can do complex validation and processing on the client if you want. Swing provides more efficient communications as well, since, like AJAX, only data is transferred between the client and the server (no UI code). There's only one little problem (well, ok, two) - how will we communicate to the server? And how will we bind the data to the user interface?

The Web stack provides mature and well-understood transport and binding layers via HTTP, JSP, JSF, AJAX, and frameworks Struts. If we are to use Swing to provide a richer user interface to the user, we must also provide a simpler data binding and transport solution that is at least as good as that provided using the typical Web stack. Fortunately the Java space has been maturing in this area and there are a number of options available.

What To Do When There's More Application "Plumbing" Code Than Custom Business Logic
What is plumbing? Communications and binding are part of what I call application plumbing - i.e., required for the application to function, but which aren't seen by the customer and don't provide value to the customer (as the business logic should).

The problem with complex distributed applications (enterprise apps) is that they require quite a bit of plumbing. Frequently you spend more time on the plumbing than on the code that provides value to the customer. This is drudge code. It has to be written, but solves well-understood problems and doesn't require creativity or (typically) differentiate your product from any other product.

Savings #3: Reduce Code by Using Frameworks Based on Open Standards
As previously referenced, just the plumbing needed to save and retrieve information from the database can comprise 30%-40% of your application code. When you add data transport, data binding, and perhaps a Model-View-Controller to the application, your application may consist of 80%-90% plumbing. The goal is to spend as little time on plumbing as possible so you can focus on the business logic that provides value to the customer. What's the solution?

Development Simplification Rule
Use frameworks based on open standards to provide the "plumbing" for your application so you can focus on the custom business logic. In general, the frameworks should:

1. Be based on open standards => Therefore they will be supportable and extendable
2. Replace roll-your-own "plumbing" => Reducing the code you write and maintain
3. Provide advanced features/functionality => Features you may not have the time or expertise to develop in-house.
   Additional things to look for:
4. Wizards => Speed up development by generating code for you
5. Happy customers => Talk to people that are using the framework to see what their experiences have been. Browse the framework forums to get a sense for the types of problems developers experience while using the framework and how they have been solved.

A good example of a plumbing framework that provides enhanced functionality while reducing the code you need to write and maintain is Struts. Frameworks are great - but you still need to decide which ones to use (if any) and when to use them. One way to evaluate frameworks (after they've met the above mentioned criteria) is to take a look at how much work they'll save you - i.e., how much of the application scope they cover (see Figure 3). As previously shown, an object database covers quite a bit of the server-side development for you automatically.

In our case, we have to identify frameworks we can use with a Swing client to provide data binding and transport functionality to our application. What are we talking about when we say "data transport" and "data binding"?

Data Transport
Data Transport is how the information is sent between the client and the server. Since Swing is written in Java, you can use just about any kind of transport technology and protocol you want to - Sockets, RMI, XML-RPC, HTTP, etc. It really comes down to which one meets your application's needs. These day's it's common to communicate over port 80 so you don't have to open other firewall ports to use your application. If you're running only in a corporate network, perhaps you'll leverage Swing's strong support for managing Sockets. Alternately, you may want to use HTTP as demonstrated in the article "Struts Meets Swing" (see references) that explains how to connect a Swing client to a Struts application.

Frameworks available that provide data transport include: Canoo's ULC, Insitech's XTT and JDNC. Canoo manages communications between "half-objects" synchronizing the objects on the client with those on the server. Insitech's XTT uses XML over HTTP to pass data and objects between the client and the server.

Data Binding
Data binding is simply a term for synchronizing the presentation layer with the model layer or to put it more simply, tying a form input field to an object property. A robust data binding solution will automatically update the presentation layer if the model layer changes and vice versa. If your presentation layer and persistence layer are on the same machine, this is very straightforward. However, if you're operating across a network, you have to deal with the data transport as well.

The number of data binding solutions has increased significantly in the last year or so - so you'll have to do your homework and review them to decide which one best meets your needs. Here's a sampling: JGoodies, Lazlo, JDNC, Canoo ULC, Insitech XTT, Oracle AD, and Spring Rich. Besides synchronizing the data between the presentation and models, some of these frameworks take care of data transport and persistence as well. By using these binding and transport frameworks, more of the plumbing of an application is taken care of automatically, further reducing the development time and the amount of code that has to be maintained. I'm now going to demonstrate how much work can be saved (and how quickly you can develop) by using some of the available frameworks.

Visualizing the Savings
Let's see how two different binding and transport frameworks assist us in reducing the amount of code we have to develop for the left side of the software application diagram (see Figure 4 and Figure 5).

Canoo's ULC framework simplifies your life by synchronizing data on the server with the presentation layer. It provides a library of components, half-objects, that are placed on your forms and bound to their other half on the server. You don't have to write the binding code or worry about the client/server communications - it's taken care of for you.

Insitech's XTT provides binding and data synchronization between standard Swing components and relational or object data sources. As you can see from the diagram above, not only does XTT bind data with the presentation layer, it also transports it to the server and interacts directly with the persistence layer (either an object or relational database). This further reduces the amount of code you have to write and maintain. XTT ships with a collection of standard Swing components that have been extended to make them XTT-aware, but any Java component can be extended to make it usable by the framework. XTT also provides a simple mechanism for making remote method calls to server-side objects and returning serializable objects to the client.

Using either the Canoo or Insitech framework will dramatically speed up your development.

Wizards
Wizards can speed up development even more by generating code for you. However, make sure the code generated is readable and maintainable. Figure 6 shows a fully functional Swing form generated with the XTT Form Wizard that shows a department and all its employees.