I recently got the security card for entering our Pennsylvania offices. The badge attaches to a hook that's linked to the string that goes around my neck so I can carry the badge at all times. I'm sure you know the type of setup I'm talking about. The JavaOne badges handed out this year were of the same type. As I examined this "gadget" more closely, I noticed that the hook is attached to a clasp, and the clasp snaps into a socket at the other end. Another piece allows me to tighten or loosen the string around my neck.

For a simple security badge holder, this gadget is really quite sophisticated. All the pieces fit together so well. At first I was quite impressed by the design. You can detach the badge, the clasp, the string - all the pieces that connect so well to each other. Then I started wondering why the manufacturer had designed such a complex system for such a simple application.

In the software world plug-and-play is a great concept. Good architectures should always be designed with component reuse in mind. However, overzealous ones often have a tendency to overdesign for reuse. It's very important to rein in the design into the context of the real business problem that applications built on the architecture try to solve. J2EE is a great platform for component-based development and promotes the design of reusable components. Along with the APIs, it offers guidelines and best practices for plugging together components to build complete applications. Design patterns should be carefully examined before applying them to a particular application. In the real world, performance, timing constraints, high availability, and other factors become additional criteria for designing a feasible solution.

For example, recall last month's discussion on the connectivity to EIS sources from the J2EE platform. The J2EE Connector Architecture (J2EE CA) provides connectivity via resource adapters to legacy, ERP, and CRM systems. However, this only supports synchronous communications. Support for asynchronous communications is expected in the next release of the spec. An alternative for asynchronous interaction is to use message-driven beans, that is, JMS. This is the advantage of open, pluggable APIs. However, mixing the two paradigms will have repercussions on the application. Issues such as performance and transaction management will have to be addressed by the application designer. The alternative in the market is to use a direct ERP adapter, such as one from WebMethods or Attunity. While WebLogic and WebMethods are working on a relationship that enables WebLogic's implementation of J2EE CA to utilize WebMethods' platform, in addition to the issues of performance, transaction integrity, and security, application designers will also have to consider the licensing and total cost of ownership (TCO) of using two application environments.

Another example is the EJB model. Until EJB 2.0, whether a component was local or remote, it was addressed via remote interfaces, which meant there was always a network hop (or RMI call) to get to an EJB component. Although application server vendors offered optimization for local component access, the spec didn't enforce this. In other words, you could plug in any component and it would act as a remote component. Luckily the local interfaces in EJB 2.0 address this problem.

Speaking of local interfaces, we have an excellent article in this issue by Alex Pestrikov. In addition to our bimonthly column on Core J2EE Patterns, the feature this month is an article on the MVC pattern in a Web application. Add to this our regular J2EE FAQs and some top-notch articles and you have another great issue.