Featured White Papers

• Why choose an Open Source BPM?
• 10 FAQs on Business Process Management
• Best Practices for Getting Started with BPM
• Free Your Devs From The Pain Of Java Redeploys
• Increase Velocity 40% by Using JRebel
• What Developers Want: The End of Application Redeploys
• Developer Productivity Report: Java Tools, Tech, Devs, and Data
• Coding with JRebel: Java Forever Changed
• Utilizing Fast Testing to Transform Java Development
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• APIs for Java Programmers: Manage & Convert DOC, XLS, PPT, PDF & More

• Instantly Preview Java Code Changes: JRebel.com

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

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

Page 5 of 7

Problem

How do you arrange application functionality or responsibility among distributed processing contexts to maximize MREPLICS features?

Forces

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.