By Nitin Bharti

April 2002

Design patterns were the main area of focus on the second day of EJB for Architects. Partha discussed The Strategy Pattern, the Session Facade, The Business Delegate, DTO's and various other patterns which catered to application-specific needs. JMS and Message Driven Beans occupied a good part of the afternoon followed by a lead into BMP and CMP 2.0. I managed to talk to a few students during lunch and at the end of the day to get their insight into some of the things they gained from the day's topics.

The morning kicked off with Partha jumping right into some of the more fundamental EJB Design Patterns. The first of these were the Strategy and Facade patterns. The Strategy Pattern helps you separate your data from your logic into two separate 'layers'. This ensures that your entity beans simply represent your data and all business logic resides in a session bean that acts as a front to your entity bean. The Facade Pattern takes this a level higher by creating a front end for multiple entity bean access. Using this pattern, a session bean can talk to multiple session beans that front other entity beans. The benefit is again that all application logic is encoded inside the facades and entity beans need to only worry about their respective data logic. The large number of network calls the client would've otherwise made directly to the entity bean have now been reduced by delegating all requests to the session facade.

Reducing network overhead seemed to be a prevalent theme in the discussion of patterns. This is also a motivation in using the Data Transfer Object (DTO) pattern. "It's an accepted practice in the industry to let your DTO mirror your entity bean" explained Partha. You can do a lot of cool things with DTOs. Aside from simply sending them over the wire, you can use a DTO factory and reflection on the client side to selectively pick out the desired attributes from an entity's DTO. The entity bean 'stuffs' its DTO with its corresponding values and sends it to the client; however, if the client only wants a subset of these values it can create another DTO (using a custom DTO factory class) that take only the selected values from the entity bean DTO. It does this using reflection.

JMS and Message Driven Beans quickly became hot topics of discussion. During lunch, I spoke with Gopal Pillai of Rivenet, an insurance company running Weblogic 5.1, who came to the course in hopes of solving a JMS issue he was having with both Weblogic 5.1 and 6.1. "Whereas before I thought the problem was application-specific, after today's discussion, I think the problem could be implementation-specific," said an enthusiastic Pillai.

In a related discussion during one of the 10 minute breaks given roughly every hour, where people step outside to freshen up, enjoy some complimentary coffee or freshly baked cookies provided daily by the facility staff, I asked Gopal what he found useful about today's patterns discussion. "The course is helping me think about some of the mistakes we may have made. For example, we don't have servlets at all. Most of our things are done with JSPs. I mean a JSP calling a session bean. There is no controller app so we may try to implement that. Eventhough we were thinking of using MVC1, we can't yet because we don't have a controller yet, eventhough we are trying to use JSP as a controller it's not something we can really implement with JSP."

Partha talked earlier in the morning about the mistake people often make with JSPs by trying to use them as controllers. "JSPs help you separate your view layer from your controller layer. JSPs are not easy to debug or maintain," said Partha trying to drive home the point that 'controller' logic shouldn't reside in JSPs but should rather live inside a servlet. "People equate JSP's with servlets because JSP's are in fact compiled into servlets, but their functionality is different."

Towards the end of the day, Partha eased the class into asynchronous J2EE messaging using JMS. There are basically two types of asynchronous messaging: 1) point-to-point and 2) publish subscribe. In point-to-point, some MOM (message oriented middleware) stores messages in a queue, which waits for the client to pick them up. Publish subscribe messaging supports topics, which is a way for the message to be broadcast to multiple receivers of the message. The benefits of using message oriented middleware is that it can provide your messages with a quality of service such as security and clustering.

A Message Driven bean is an asynchronous session bean that has no remote or local interface. It only has a bean implementation of an onMessage() method which receives a Message type. The need for Message Driven Beans (MDBs) arises when a client request uses methods of multiple EJB's in a transaction and cannot wait for a response. A server-side intermediary to the client is needed, but one that doesn't require the client to block and wait. MDB's solve this problem, creating a fault tolerant, asynchronous facade. Other benefits of MDBs include low network overhead, scalability, decoupling of the client and server, and the prioritization of messages.

Ken Kaufman of Trilegiant Corporation also enrolled in the course in hopes of gaining J2EE architectural wisdom. It seems he came to the right place. Kaufman has a strong conceptual background of Java and J2EE. However, at the end of the day he was visibly exhausted from the 8 hours of intense J2EE immersion, yet I noticed a smile expressing satisfaction from the day's architectural musings. The smile perhaps wasn't too disimilar to the one The Buddha may have bore upon achieving Nirvana. Yes, Kaufman was tasting J2EE enlightenment.

"The project I'm currently working on is a financial transaction processing system which is not currently into a middle tier type architecture" explained Kaufman. "It's a legacy system using Java OO developed a few years ago but lacking in the technology we're talking about now."

"Some of the patterns in particular I think we'll be able to apply well in our system. I think we could use message driven beans a lot. We process hundreds of thousands transactions a day and we need to invoice them and present them to users. A lot of this processing is asynchronous. We don't need users to wait for invoices to be created and approved. I was really excited to think about how we could use Message Driven Beans to alleviate some of the weighting on the client side. We've hit a wall in terms of scalability. The system really can't process the number of transactions we need to do in a particular day. I think we could really leverage some of the EJB architectures to take some of the load off the batch processing foundation that we have now."

Overall, on the second day, the class seemed more hyped up talking about patterns and J2EE messaging. As interesting as J2EE Project Management was on the first day, it was good to finally dive into J2EE design strategies using some pretty cool technologies. Tomorrow's class continues with the discussion of BMP and CMP which was briefly introduced today towards the end of the day, looks into the the new features of CMP 2.0 and moves into an indepth study of JDO, EJB 2.0 persistence, and complex persistence.

PRINTER FRIENDLY VERSION