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 7 of 7

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.

About the author

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.

Read more about Tools & Methods in JavaWorld's Tools & Methods section.

  • Print
  • Feedback

Resources