Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

The Smart Choice for Smart Clients: J2EE or .NET?

Don't know where to begin with smart-client implementation or whether J2EE or .NET is the better choice for it? Follow a firm as it uses the .NET and J2EE frameworks to construct a smart-client application requiring online/offline access, no-touch deployment, and data synchronization.


advertisement
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.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date