More action with Struts 2
In a recent review of Struts 2 in Action, JW Blogger Oleg Mikheev notes that Struts 2 is "just a collection of extensions built upon WebWork, which is ultimately the right thing to learn before starting a Struts 2 project." While Struts 2 has some architectural flaws, Oleg calls WebWork well-designed, well-tested, and reliable. What are your experiences using Struts 2 and WebWork?

Also see "Hello World the WebWork way," a JavaWorld excerpt from WebWork in Action, by Patrick Lightbody and Jason Carreira.

Newsletter sign-up

Sign up for our technology specific newsletters.

Enterprise Java
View all newsletters
Email Address:
JavaWorld.com > Java Enterprise Edition >

An ounce of prevention: Avoid J2EE data layer bottlenecks

Best practices for tackling data bottlenecks within J2EE environments

By Christopher Keene, JavaWorld.com, 04/05/04

Page 3 of 4

Cache function J2EE caching Intelligent caching Benefit
Object access Objects accessible only within transactions Objects accessible across transactions Easier to access cached objects
Object query By reference and primary key only By reference, primary key, attribute, relationship, and indexed queries Cache queries speed performance
Object model Only caches simple objects, no relationships Caches complete object model, including relationships No "impedance mismatch" with cache
Clustering Only sends invalidation sync messages Sends changed state in sync messages Clustered caches have complete state
Completeness No sync messages sent for inserts, relationship changes All cache changes are replicated across caches Clustered caches are consistent with database
Coherency No guaranteed messaging, can lose sync messages Guaranteed sync messaging Clustered caches have guaranteed integrity
Portability Proprietary-caching capabilities not portable across J2EE servers Supports WebLogic, WebSphere, Java, C++, .Net Caches can sync across multiple platforms


For data-intensive applications, the data access layer must be developed to support the performance, scalability, and availability requirements of the business processes or a bottleneck results. Standard J2EE servers fail to meet these requirements out of the box, so data-intensive applications require either significant hand-coding to get around the J2EE framework's limitations or purchase of a third-party data services product that integrates mapping and caching transparently within the J2EE framework.

Data services layers for data-intensive J2EE applications

Over the last two years, several software companies have introduced data services layers that incorporate object-relational mapping with intelligent caching capabilities and transparently integrate with J2EE servers. These products can address both model-intensive and transaction-intensive applications, but are particularly suited to solve the most serious data bottlenecks created by data-intensive applications. Examples include EdgeXtend from Persistence Software and TopLink from Oracle.

Data services products offer a "best-of-breed" antidote to the bottlenecks inherent in the J2EE architecture. A data services layer's capabilities include:

  • Model-driven development: A data services layer should use a model-driven approach to generate data objects that map to relational data. The data services layer tools should integrate with data dictionaries with UML (Unified Modeling Language) tools.
  • Seamless J2EE integration: Generated entity EJBs (Enterprise JavaBeans) should integrate seamlessly within the J2EE server, for example, by using the JCA (Java Connector Architecture) transaction interface to integrate with the persistent object lifecycle.
  • Transparent caching: All data objects implement transparent caching, with caching rules specified through a configuration file.
  • Guaranteed synchronization: Cache data changes propagate reliably to other caches, enabling scalability, failover, and high availability using JMS (Java Message Service), Tibco, or MQ.
  • Rule-based alert propagation: Cache data changes may propagate to other servers, devices, or users based on propagation rules.
  • Cross-platform: A data services layer should support multiple J2EE servers and be capable of running in a pure Java environment. Ideally, the data services layer should support multiple application platforms, including C++, Portable Java Objects (PDOs), J2EE objects (entity beans), and C# assemblies.


Figure 4 shows how a data services layer fits into a standard J2EE architecture. Note that the API for the data services layer can be either entity beans or plain old Java objects, so that presence of the data services layer is transparent to the rest of the application.

Figure 4. J2EE data services layer. Click on thumbnail to view full-sized image.

Data services layer application example

To illustrate the benefits offered by a data services layer, consider a financial portfolio management application with the following requirements:

  • Complex business entities: Portfolios, positions, and security data, whose cardinality is in hundreds, thousands, and tens of thousands, respectively
  • Real-time position updates: Any change to a model portfolio causes automatic changes to its child portfolios, each of which is subject to a set of business rules
  • Large numbers of users: Hundreds of portfolio managers use the application to actively manage the portfolios and/or to model "what-if" scenarios


To meet these business requirements, any Java server-based solution must provide:

  • Near real-time performance guarantees
  • Guaranteed high levels of business data integrity and 24-7 operation
  • Ability to scale along with increased business loads


In building the portfolio management application, a best practices data services layer first provides a model-driven approach for defining the object model and specifying how it should map to the database for maximum efficiency. Using native database APIs and database-specific performance features will help optimize the mapping performance.

For example, data services layer tools can accept object-modeling input from a data dictionary, Rational Rose or Eclipse, and then use that information to generate standard entity beans that run transparently inside the J2EE server.

On deployment of the portfolio management application, a best practices data services layer caches local copies of frequently accessed business data, assuring maximum throughput rates, and cooperates in synchronizing data changes with other caches, ensuring that the data's local copy is synchronized across all server instances. The data services layer effectively provides a data virtualization model for the J2EE architectures, greatly reducing the complexity of scaling a J2EE application, while simultaneously enhancing its robustness and integrity.

For distributed applications, a data services layer can provide even greater value. Each geographically distributed, independent server instance uses a local cache as its data layer. The local cache handles read access in these remote sites, greatly accelerating performance, while writes still write back to the primary database, providing centralized data management.

Discuss

Start a new discussion or jump into one of the threads below:

Subject Replies Last post
. An ounce of prevention: Avoid J2EE data layer bott
By JavaWorld
( Pages 1 2 all ) 		28 07/19/08 06:57 AM
by Anonymous
. Too shallow to be useful
By Art Majors 		4 07/19/08 02:56 AM
by Anonymous
. OODBMS for model intensive
By Harel 		0 07/12/08 04:31 PM
by Anonymous
. What a shallow article
By GKL 		0 04/09/04 12:55 PM
by Anonymous
. Data Layers
By L Cismaru 		0 04/05/04 08:49 PM
by Anonymous


Resources