|
6 Best Practices for J2EE Architecture
Leverage "in-the-trench" J2EE best practices to improve the architecture and design of your existing and future J2EE applications.
by Tarak Modi
Posted June 28, 2004
Numerous articles have discussed J2EE best practices. So, why am I writing another one, and how is this article any different from—or better than—the others?
First, this article is aimed at practicing technical architects. To avoid insulting anyone's intelligence, I'll avoid the cliché best practices such as "build daily," "test everything," and "integrate often." Any projects with architects worth their salt would have well-defined team structures with properly delineated roles. They would also have properly documented processes for conducting code reviews, building the code (daily and on-demand), testing (unit, integration, and system), deployment, and configuration/release management.
Second, I'll skip commonly touted best practices such as "interface-based design," "use well-known design patterns," and "use service-oriented architecture." Instead, I'll focus on six (out of many) "in-the-trench" lessons I have learned and followed over the years. Finally, this article's intent is to get you thinking about your architecture; providing working code samples or solutions is beyond this article's scope. Without further ado, let's examine the six lessons.
Lesson 1: Never Shortcut Server-Side Validation
As a software consultant, I've had the opportunity not only to design and implement Web applications, but to assess/audit many Web applications as well. I often encounter Web pages within the application that are sophisticated and packed with client-side JavaScript that performs extensive checks on user-entered data. Even the HTML elements have data validation attributes such as MAXLENGTH. The HTML form is submitted only upon successful validation of all the entered data. As a result, the server side happily performs the business logic once it receives the posted form (request).
Do you see the problem here? The developers have made several major assumptions. For example, they assume all Web application users will be equally honest. The developers also assume all users will always access the Web application through the browser(s) they've tested. And the list goes on. These developers have forgotten that it's easy to simulate browser-like behavior through the command line using freely available tools. In fact, you can send almost any "posted" form by typing in the appropriate URL in the browser window; although, you can easily prevent such "form posting" by disabling GET requests for these pages. But you can't prevent people from simulating or even creating their own browsers to hack into your system.
The underlying problem is that the developers have failed to recognize the main difference between client-side validation and server-side validation. The main difference between the two is not where the validation occurs, such as on the client or on the server. The main difference is in the purpose behind the validation.
Back to top
|