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

Build better J2EE applications with a high-level pattern language

1 2 Page 2
Page 2 of 2

Traditionally, developers draw a UI with an interface-building tool and then write blocks of code that execute application actions in response to user input. Many design methodologies emphasize starting with the UI, which all too often solidifies into a final system design. The result: a program organized around UI elements and user actions on those elements, with persistent data manipulation, application functionality, and display code completely intertwined. The code typically ends up with numerous if-else statements.

Code structured in such a fashion can succeed for small, single-user systems whose functionality requirements change slowly over time. However, such a structure proves inadequate for large, long-term, distributed projects because it exhibits:

  • Poor modularity: Due to monolithic fashion and excess interdependency, it is much more difficult to achieve modular systems. Indeed, a change to the code anywhere produces side effects everywhere. Unit tests prove difficult too.
  • Poor reusability: Your code will be less reusable because each component depends on many other components. Dependencies among components make the components less usable in other contexts.
  • Poor extensibility: When new functional requirements appear, it's difficult to find the code that needs to be changed or extended. Moreover, new interfaces must be developed from scratch, since the control logic is buried in the code.
  • Poor consistency: Sophisticated applications often require multiple ways to view and manipulate the same data. The result is often similar data calculated or accessed in different ways, resulting in display-value inconsistencies. Even if the displayed data are correct, any change to the data display must be updated in multiple places, opening the door for flaws.
  • Poor scalability: It is difficult to increase workloads -- the solution simply doesn't scale.
  • Not event-driven: A J2EE application differs greatly from transitional applications: it is networked and event-driven by nature.
  • Poor portability: Porting the application can become much more difficult. If business-logic code accesses a particular vendor's product (a database, for example) from everywhere in the application, platform moves become next to impossible.

The solution

To solve the problem, put your application into different layers, a move considered to be a better practice since it separates conceptually different issues.

From an architectural point of view, partition your system into a number of layers and place them on top of one another such that services of layer n + 1 consist mostly of the services provided by layer n or a combination of sublayers. This moves us significantly toward a MREPLICS solution because, within the same layer, all the components work at the same level of abstraction or the same functionality.

As shown in Figure 3, we need to have a virtual functionality provide_Service() method. Figure 3, section (a) illustrates how it looks when done in a monolithic programming fashion; components engage in cross talk whenever necessary at coding time. It would be difficult to extend the code to provide more functionality, in particular if the programmer responsible were no longer with the company. In contrast, Figure 3, section (b) illustrates the correct way to handle the situation: layer the system and allow components to talk to different layers through a unified interface.

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.

Pattern name: REAI architecture

Context

The company in question, TSP, needs to integrate with remote services including multiple, independent backend services that may use incompatible technologies. The architecture must determine what method invocations and messages go to what destinations, under what conditions, and what recipients do when receiving them.

The problem

How do you architect the application to integrate and automate the processes without depending on the backend services details? At the same time, can the rules of process flows be introduced and modified quickly by nonprogrammers in a cost-effective, manageable, and changeable fashion?

Force

For the processor, EAI (Enterprise Application Integration) presents challenging tasks. First, in an EAI environment, the processor must accommodate heterogeneous systems and applications. Second, it must launch each application required in the process flow. Finally, it must deliver and receive data in whatever forms the applications can handle. Considering these challenges, the processor will need message broker capabilities, such as the ability to transform and move data.

The solution

The REAI architectural pattern, as shown in Figure 5, can solve our problem by using a set of decoupled components, resulting in greater flexibility, maintainability, and changeability. The REAI architectural pattern consists of five modules:

  • Task Scheduler
  • Biz Rules
  • Rule Engine
  • Data Handler
  • Dispatcher
Figure 5: The REAI architecture pattern Click on thumbnail to view full-size image. (7 KB)

To reach our solution, tear integration business-process logic out of application objects and encapsulate complex processes in rule scripts. This way error rates fall, and manageability, changeability, and lower developer intervention will be achieved.

Scheduler schedules B2B tasks, and the Rule Engine is loaded dynamically so that the application exists independently of any specific engine implementation. The engine executes rules and asserts business actions. The Data Handle layer ensures that when data reaches its destination, the format of the data is what's expected. The Data Handle also secures the XML file if such security measures are required.

A B2B Dispatcher registers remote services and locates, adds, and removes exchange and remote services. It also serves as a gateway to available messaging services. The dispatcher employing these services should not depend on specific remote system details to guarantee portability and interoperability. If Sun's Java Connector Architecture (JCA) is adopted by major application server vendors and the adapters become commercially available, then E++ may replace the dispatcher with JCA in future releases. However, at present the dispatcher is still valuable in helping applications integrate vendor-specific backend systems synchronously or asynchronously.

The REAI architecture provides the following benefits:

  • It works with nonstandard adapters or facades of remote services
  • One can change services or add new ones without modifications to the processing components
  • It uses EJBs to conduct actual business, thus leveraging the existing security and transaction capability of the EJB container
  • When network or remote server failures occur, new servers can be activated at a different network node without any impact upon clients

According to experience, REAI should be designed such that B2B administrators can control it in a quasi-seamless fashion, even with automation in default settings.

Conclusion

The E++ pattern language is a framework and pattern language for the development of e-business systems on the J2EE platform. As we've seen, E++ possesses the following important advantages:

  • E++ can be developed prior to the completion of business-requirements gathering because it represents a flexible framework with event-based control logic. One needs only to create related events, event handlers, their EJB Model, Web Model, and business rules. The application control logic remains the same over time. Hence, the amount of time lost on coding that is often experienced when using Java may be reduced.
  • It is easy to integrate different applications within an E++ master application. The framework allows the realization of an open and scalable system. The J2EE standard component implementation makes the framework truly portable over different operating systems and different application servers.
  • E++ promotes a MREPICS-compliant application framework

In Part 2, we will work through E++'s detailed design patterns, so stay tuned.

Bin Yang is chief architect of Telegea, a B2B and B2C software solution company for the network telecommunication industry. With a background in postdoctoral studies in physics at Massachusetts Institute of Technology, he has been programming in C-like languages since 1988 with a dozen publications in computer simulations. A Sun-certified Java 2 architect and programmer, he has been building J2EE enterprise applications and frameworks for more than two years. A former MIT ballroom dance-club member, he loves practicing dance patterns when not studying design patterns. Bin would like to thank Dr. M. Farkhondeh and F. Wang of MIT for useful discussions.

Learn more about this topic

1 2 Page 2
Page 2 of 2