Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

JavaWorld.com > Java Development Tools >

E++: A pattern language for J2EE applications, Part 1

Build better J2EE applications with a high-level pattern language

By Bin Yang, JavaWorld.com, 04/20/01

  • Print
  • Feedback

Page 6 of 7

Figure 3: The Layered Architecture
Click on thumbnail to view full-size
image. (9 KB)



Although there are numerous benefits and advantages of a layered architecture, including more freedom and increased flexibility, it does leave designers with more responsibilities. Indeed, they themselves have to design interfaces between layers and ensure application consistency and availability. Fortunately E++ does these tasks for us.

Pattern name: MVC architecture

Context

After adopting the Layered Architecture, we want to determine the number of layers needed, as well as establish the control and communication mechanism of the inter- and intra-layers such that the architecture is simple, more MREPICS-compatible, and maintainable over the long term.

The problem

How do we determine the most appropriate number of layers to have a simple but effective control and communication mechanism?

The forces

Compared with traditional programs, a Web-based J2EE program must offer a UI for various users with different roles. The UI is also prone to change, so a UI tightly interwoven via the application's other parts will prove expensive and error-prone.

At the same time, a synchronization issue exists between the front and back layers; application models must be consistent across all layers. We need a more dedicated inter- and intra-layer control and communication mechanism.

Figure 4: The MVC architecture pattern
Click on thumbnail to view full-size
image. (19 KB)



The solution

As shown in Figure 4, MVC represents the solution to our problem. The pattern requires that each of these -- model, view, and control -- reside in different object clusters.

The model contains the functional core of the application. It encapsulates the appropriate data and performs application-specific processing. The model also provides functions to access its data used by view components to acquire the data to be displayed.

View components present information to the user. Different views present the model's information in different ways. Each view is involved in an update procedure activated by the event model. When the update procedure is called, a view retrieves the current data values to be displayed from the model, and puts them on the screen.

The controller is function-based. In our case study there will be three control models for three different functionalities: B2C, B2B, and TSP administration. The control module is mapped into a composition of the component set. It is the only link between the model and the view.

Applying the MVC architecture to the standard J2EE platform, we have the fine-grain four tiers as shown in Figure 4, section (b):

  • EJB Model -- EJB encapsulating business logic
  • EJB Control -- to control EJBs and JavaBeans
  • Web Control/Model -- Web-tier control tags and JavaBeans
  • View -- JSP, servlets, JavaBeans, or Java applet or application


These four layers can benefit your application in numerous ways. For example, because of the architecture's simplicity, it is easy to explain and demonstrate where each object's role fits into the big picture. Moreover, if the E++ language is carefully followed, the potential for reuse in different projects is guaranteed.

  • Print
  • Feedback

Resources