n a world of distributed computing, the demand for smart-client applications is growing quickly. IT managers realize they must keep users happy—the user’s experience will make or break any application—while leveraging their existing service-oriented architectures (SOAs). The problem is that most development teams either do not know where to begin or they are unprepared for the challenges that come with smart-client implementation. This article follows a hypothetical accounting firm that uses the .NET and J2EE frameworks to construct a smart-client application requiring online/offline access, no-touch deployment, and data synchronization. It also offers an assessment of which framework is best for a given aspect of smart-client implementation.

Smart Client: Reach and Rich in One
Development shops in large companies make decisions every day that affect the productivity of their businesses. They commit a lot of time to determining the scope of an application. Its functionality, size, technical requirements, and intended audience all play vital roles in enabling a developer to make intelligent decisions. Missing or incorrect information usually leads to poor choices, which often throw the proverbial monkey wrench in to even the most well-oiled machine. The result is complete project failure.

Perhaps the most important decision in determining a project’s scope is choosing whether it will be Rich or Reach. From an architecture standpoint, the distinction is simple: where is the business logic located? Rich clients place business logic on the client, whereas “reaching” applications keep business logic on the server and away from users. This subtle distinction generally results in major application behavioral differences that are readily apparent to the user.

Rich clients provide an attractive user interface, quick response times, and features that make the user experience very productive. The problem is that rich clients are usually platform specific, cumbersome to deploy, and require a great deal of engineering to network. A thin-client approach can help localize these issues, but they still remain a substantial inconvenience.

Reach, the counterpart to Rich, is an approach that requires no user deployment, is inherently networked, and can deliver your application to anyone, anywhere—but it has a catch. A far-reaching application can deliver a poor user experience. When you search for driving directions online, for example, you are using an application built with Reach. Anyone with a Web browser can access the application and it requires no setup. Although it is a useful tool, the amount of time and energy (visiting multiple pages and fiddling with drop-down boxes) required to complete one simple task is woefully inefficient. Imagine how much more you could accomplish on a different task given the same amount of time and your favorite spreadsheet.

This trade-off can affect productivity just as much as a rich client’s inability to reach all of your users. The conundrum often has software development teams asking, “Can’t we have our Rich and Reach it too?”

Good news: you can.

Although it presents its own hurdles, a smart client represents the marriage of Rich and Reach by addressing the issues of user experience, networking, and application deployment all at once. The solution goes back to the fundamental difference between the Rich and Reach approaches: the location of business logic. In a smart-client application, the location is on both the client and server sides. But this approach merger does not come without its price. It requires significant engineering. Luckily, the two most widely used frameworks, J2EE and .NET, both offer solutions to help tackle most, if not all, of the obstacles.

This article examines features within the J2EE and .NET frameworks that address three of the most common challenges a development team will face when building a smart-client application: implementation, deployment, and data synchronization.

Smart-client Scenario: Accounting App
Imagine an application in which accountants obtain electronic copies of tax returns that they must process and then file with the state and federal governments. This is a perfect example in which a smart-client approach would benefit both the accountant and the accounting firm.

Filing tax returns requires a lot of number checking, document referencing, and calculation. Doing these tasks on paper is tedious enough, let alone navigating a slow-responding, hard-to-work-with front end such as a Web site. Accountants require quick access to information such as investments and the previous year’s return, so they clearly want a Rich experience. However, other requirements, such as the following, prevent the firm from taking the rich-client approach:

• The firm’s clients uploaded tax-return information via a Web site, and the firm must in turn place it in a central repository. This requires that the application adapt to a client/server model, because many an accountant will be accessing the same information simultaneously.
• As tax laws vary from year to year, a new version of the software will be released before each tax season. This requires that every client machine undergo some sort of manual installation or update process. Processes such as these often incur headaches and wasted time because of the inevitable unique troubleshooting requirements.
• Different accountants will be accessing and updating the same information simultaneously. When this happens, the application will have to account for and resolve versioning conflicts in the data.

For these reasons, along with the fact that users will need a Rich experience, this hypothetical firm decides to tackle the daunting task of building a smart-client application. The first question they need to ask themselves is where to begin.

Accounting App Implementation
Should we employ .NET Web services or J2EE Web applications?—that is the question. Both technologies usually lock you into one framework or the other, and although each choice has its pros and cons, both essentially do the same thing. Web services and Web applications provide the SOA required to share business logic responsibilities between client and server.

The first step in implementing a smart-client application is to determine which functionality should reside on the client side and which on the server side. The accounting firm decides it would be beneficial for accountants to be able to work on tax returns even when they are not connected to the network, allowing employees who do not have Internet access to take their work home with them. This means that the server will contain no logic with regards to actually doing taxes. All of this functionality will reside in the client application instead. However, users with no Internet access will not be able to file processed tax returns with the government because that function obviously belongs on the server side.

Now that it has separated the logic in its application, the firm can begin to build its services. The following examples show what the firm’s server-side API might look like as either a .NET Web service or a J2EE Enterprise Java Bean (EJB):

Server-side API as a .NET Web Service

Server-side API as a J2EE Enterprise Java Bean

When the user is online, he or she will be able to pull new tax returns from the data store, upload processed returns, and file those returns with the state and federal governments. Meanwhile, the user can perform all work on a downloaded return as if he or she were using a standalone application. Although this client-side logic is convenient for everyday use, it poses major hassles when the time comes to update that logic.

Accounting App Deployment
One of the driving factors that led to Web applications’ current domination of the market was ease of deployment. When the business logic of a Web application changes, only the server end of an application needs to be updated and redeployed. The same cannot be said for standalone applications. When a new version is released, the user usually has to go through some sort of manual update or installation process. Smart-client applications, on the other hand, can update themselves when online, and they require no user intervention to do so.

A technology called Java Web Start (JWS) enables no-touch deployment in a J2EE architecture. Developing an application for deployment with JWS is almost identical to developing a standalone Java application. The key differences are that your application and its resources must be delivered via one or more jar files. These jar files must be signed to grant the application full system access, and you will need to provide a JNLP file to detail deployment information.

In order to implement no-touch deployment using JWS, you must do the following (Click here for additional information on no-touch deployment with JWS.):

1. Install JWS on the client machine.
2. Make your application’s JNLP and jar files available via the Internet.

The following is the JNLP file for the firm’s tax-return-processing application:

JNLP File for Tax-return-processing Application

A true benefit of this approach is that it is easy to convert an existing application, simply by launching and deploying it with JWS. By comparison, the .NET framework is not as effective at separating deployment logic from application code.

Instead of repackaging an existing application to be deployed and run though a standard startup application like JWS, the .NET framework provides a means to perform no-touch deployment programmatically with the Assembly.LoadForm method in the System.Reflection class (Click here for additional information on no-touch deployment in .NET). In order to implement no-touch deployment in .NET you must do the following:

1. Create a lightweight application containing no business logic, only deployment logic.
2. Install that application on the client machine.
3. Make the fully functional business logic of your application available via the Internet in the form of DLLs.

The following sample code is from the deployment application for the firm:

Sample Code from the Deployment Application

Although writing a deployment application is fairly simple in .NET, JWS clearly gives J2EE the upper hand. However, the almost even match-up between .NET and J2EE swings in the other direction when you deal with data synchronization.

Synchronize This!
To this point, this article has discussed how the J2EE and .NET frameworks, in one form or another, address the needs of developers creating smart-client applications. However for the final obstacle, data synchronization, only one of the frameworks provides an instrument to emerge victorious: .NET.

The tax-return-processing application enables accountants to take their work home with them, but what exactly happens when a user uploads the processed version of a tax return? The server-side application will need to perform data synchronization somehow. That is, the server will be responsible for making sure a given tax return has not been revised by someone else during the time it was being processed by a given user. If it hasn’t, the server also must make sure the tax return information in the database gets updated. Developers could always accomplish this task by writing the appropriate code and SQL statements, but .NET supplies them with a glorious alternative: the DataSet class.

A DataSet object provides an in-memory representation of data from one or more tables in a database. An application can use this object not only to read data, but also to insert and update rows. When the application is ready to synchronize the in-memory data with the database, the DataSet object will generate and run the appropriate SQL to perform all synchronization. This saves programmers all the time they would otherwise spend developing (and debugging) synchronization implementations. The following is an example of this synchronization from the tax-return-processing application:

Synchronization from the Tax-return-processing Application

J2EE, on the other hand, currently offers no equivalent feature. However, this does not stop Java developers from implementing data synchronization in smart-client applications time and time again. It merely means that they have to either obtain a component similar to DataSet from a third party or code data synchronization from scratch. Since software reuse saves thousands of dollars every day, the latter choice can become expensive.

So Which Framework Should I Use, .NET or J2EE?
Unfortunately, the decision between frameworks still has no clear-cut choice. J2EE has more to offer in terms of no-touch deployment, but only .NET provides pre-packaged synchronization logic and in-memory manipulation of DataSets. As with all applications, choosing the right technology depends heavily on your specific application’s functional and technical requirements.