Download (direct link):
Figure 38.4, on the other hand, seems to eliminate all of the problems that we previously discussed. In Figure 38.4, the client application sends one big message to a gigantic "object that talks to everything." This object talks to all four databases, encapsulates all the business logic, and returns the results back to the client application. On the surface, the application design shown in Figure 38.4 seems perfect—but is it? We have definitely eliminated the bottleneck of too many network connections, and we have eliminated the tight coupling between the client and the databases, but we have now a monstrous object that is tightly coupled to the databases! This design is still inflexible, similar to the design in Figure 38.1, but we have simply added another layer.
Finally, the diagram in Figure 38.5 shows a better solution. We have a client making one network call to an object, which then calls the abstractions to the databases. The database abstractions do the database-specific logic, and the object does the workflow for our use cases. The client application passes in the customer information and symptoms of car trouble to an object, which then delegates that work to abstractions to talk to the database. Finally, when the possible problems and their respective solution part numbers are returned to the object, this information is passed back to the client in one connection. Because only one network connection happens, this creates a positive impact on performance.
Car Trouble Car Trouble
Figure 38.3 Bottleneck: too many network calls from client.
Design Strategies for Eliminating Network Bottleneck Pitfalls 339
.> Owner Database
.> Automobile Database
Car Trouble Database
Figure 38.4 The extreme: better performance, but inflexible.
Client That Talks
Looking at this scenario, we see that there could be many solutions to designing this system. Before we go into the pitfalls that could occur in each API, let's mention that the key goal for designing this system for this scenario is network performance.
Object Abstraction Database
Client That Talks
Application -> To c-------
Abstractions Car Trouble Car Trouble
Figure 38.5 A more flexible solution.
340 Item 38
EJB Design Considerations
Because we have discussed the potential design pitfalls in this scenario in depth, these pitfalls easily translate to design pitfalls using Enterprise JavaBeans. One problem similar to the poorly thought out designs shown in Figures 38.2 and 38.3 is the design solution where clients directly call entity beans. When this happens, clients become too tightly coupled to the logic of entity beans, putting unneeded logic and workflow in the client, creating multiple network transactions, and creating an architecture that is very unflexible. If the entity bean changes, the client has to change.
Luckily, session beans were made to handle transactional logic between your client and your entity beans. Instead of having your clients call your entity beans directly, have them talk to session beans that handle the transactional logic for your use case. This cuts down on the network traffic and executes the logic of a use case in one network call. This is an EJB design pattern called the Session Facade pattern and is one of the most popular patterns used in J2EE.3 In our very simple use case for our example, we could have a stateless session bean handle the workflow logic, talking to our session beans, as shown in Figure 38.6.
Of course, you could also use the EJB Command pattern to accomplish the abstraction and to package your network commands into one network call. For more information about these design patterns and for similar patterns in Enterprise JavaBeans, read EJB Design Patterns by Floyd Marinescu. It's a great book. (In fact, I had to throw away several pitfall ideas because they were described so well in that book!)
In this pitfall, we discussed network programming design that can relate to any area of Java programming—RMI, Sockets, CORBA, Web Services, or J2EE programming. As you can see by our discussions related to EJB, the basic concepts of design and programming for network performance do not change. With J2EE, we discussed the Session Facade and the Command patterns, which were similar to the solutions we discussed in Figure 38.5. In fact, the J2EE architecture itself helps the flexibility and stability of our architecture.
Figure 38.6 Using the session facade pattern.
3Marinescu. EJB Design Patterns. John Wiley & Sons, 2002.