We live in a world where abstraction is the name of the game. I used to be an avid reader of Asterix comics, and thinking of abstraction reminds me of a couple of panels in the "Obelix & Co." comic book. A Roman emissary tries to explain to the (simpleton) Obelix the intricacies of Roman economy in simple words: "Make much menhir, get much gold," or something to that effect.

I don't mean to say that we developers are simpletons. But, as my colleagues in marketing say, the presentation needs to be "dumbed-down" for the appropriate crowd. As an enterprise architect, I don't want to deal with the details of system-level programming and operating system implementations. That is one of the reasons I chose J2EE as my reference framework for implementing applications. Yes, J2EE is an abstraction, a "dumbed-down" framework for me to develop distributed applications.

One of the really neat things about Java is that it's made standard design patterns household names for the developer community. Java is built on standard design patterns and implementation guidelines. Five years ago, the majority of the programmers I talked to didn't know what design patterns were. Now, almost all Java developers are aware of Factories, Listeners, and Adapters. The reason? Core Java objects use the Factory patterns. Observer-Observable and Producer-Listener are a part of the language. Adapters and Proxies are applied all over enterprise Java applications.

J2EE Design
J2EE provides component APIs that are built on solid design principles. However, in order to apply these APIs to build enterprise applications, you need a good design base for developing robust and reusable components. The good news is that years of experience of a multitude of developers are available for other developers to apply, use, and learn from. The best approach is to consult the appropriate documentation and other resources, and not reinvent the wheel for each new application. One of the primary advantages of this approach is that your design paradigm will be supported by a larger community than just the environment that you program in. In some sense, design patterns are simply communication mechanisms for application architects, designers, and developers to share information on best design practices.

J2EE covers a lot of areas. It's impossible for a single person, or a group of developers, to acquire expertise on all of them. This problem is magnified in distributed development environments where communicating the different aspects of design and coordinating the modules of the application becomes an extremely daunting task. Design patterns help alleviate a large portion of this pain.

Sun's J2EE Blueprints provide a great starting point to help developers understand the rationale behind the design of the J2EE platform. The sample Pet Store application helps put this in the perspective of a real-world demo. However, when you design a real-world application, there are other aspects of design that you need to address. With the acceptance of J2EE as the preferred platform for building distributed applications, you'll see richer sources of information on building these applications emerge.

Starting This Month...
At JDJ, we want to address this higher level of abstraction. This month and in subsequent issues, you'll see more coverage on applying J2EE into actual applications. In this issue, John Crupi starts a bimonthly column based on his popular book Core J2EE Patterns. There is a J2EE Patterns community out there. Feel free to write to us to find out how you can learn more about J2EE Patterns. Among other excellent articles, we also have a piece on J2EE frameworks by Steven Randolf that should help you design better applications by reusing J2EE framework components. We also bring you reviews on a couple of books that address J2EE design and real-world application of J2EE frameworks.

So, return to the J2EE section, and as the Roman emissary in my Asterix comics would say: "make less factories, build much objects."