Object Relational Technologies form the backbone of most of the enterprise Java applications. Choosing the appropriate technology however is one of the most important decisions for an enterprise architect. More often than not, such a decision is either a hit or miss. Mistakes done in selecting the appropriate technology results in performance bottlenecks, lack of scalability, unreliable transaction handling etc.

More than the problem with the specific ORM technology, it's the suitability of that technology to the underlying business needs and non-functional requirements. This article aims to establish an objective architecture evaluation framework for evaluating which ORM technology best fits your project needs. Based on the requirements, one or the other technology may be appropriate.

Flexibility
For an ORM framework to be flexible, the following considerations are important

1. Do multiple options exist to access and manipulate data
   Should the project need multiple ways to access data. This would include object based way of querying data, using native SQL, using ORM specific natural query language. The architect must decide the importance of each of these methods and evaluate this parameter.
2. Does the ORM tool supports extending the various default data types, with user defined data types
   Project needs change and so there are requirements to add custom data types. The ORM tool must support this feature, should you envisage the changing needs of your project.
3. Ability to invoke interceptors on the data before it is saved, accessed or deleted
   Enterprise projects often need to add additional business validations or business logic over a period of time. Many of these changes need to be cross-functional. The ORM tool must have mechanism to intercept requests and inject such validations. This is an important factor if you foresee changes happening after the production deployment.
4. Programmatic and Declarative Configurations
   The ORM framework must provide multiple ways for it to be configured. This is important again from the perspective of how flexible the tool needs to be.

Ease of Development

1. Ability to create domain model from the database tables
   This is an important consideration if you already have database tables and you need to create domain model out of it through automatic code generation. The ORM framework must provide the appropriate utility for doing that.
2. Ability to generate database tables from the domain model
   This is an important factor when the domain model has already been created as part of MDD and database needs to be created. This would ensure that there are minimal errors during generation of database schema
3. Ability to specify natural query language for retrieval
   Typically ORM tools provide a criteria API to fire object oriented queries. However based on development experience, it is understood that this is not the best way of visualizing large and complex queries. If this is a criteria important for your project, you must ensure the availability of natural query language with the ORM tool. Support for native SQL is also important under this consideration

Reliability

1. Support for JTA transactions
   An enterprise ORM framework must support JTA transactions. This support should be both declarative as well as programmatic. This is the most important consideration for evaluating the reliability of the platform as incorrect transaction handling would be catastrophic
2. Support for Batch Processing
   Looping through individual transactions for batch processing is a perfect way to crash your system. The ORM tool must support JDBC Batch updates for batch processing.
3. Support for Caching
   Caching is important both from scalability as well as reliability perspective. Support for integrating third party cache should be an important consideration for all enterprise projects. The cache support must be distributable across the cluster as well

Scalability and Performance

1. Ability to use container or third party connection pools
   Connection pools should provide ability to scale up to increased load
2. Ability to support legacy code
   If you need support for legacy code, the ORM tool must support native invocation of stored procedures
3. Ability to optimize queries for performance
   It is very difficult to optimize a two page query written using criteria API. Infact for many complex scenarios for an enterprise application, there is a need to fire native SQL queries. These queries are also easy to optimize especially by the DBAs. If performance is a critical requirement, this factor must be considered
4. Ability to cache queries and query results
   This is an important criterion for scalability

Maintainability

1. Ability to modify domain model or DB model with minimal changes to underlying code
   This is an important factor if you foresee such changes
2. Ability to log the framework internals
   During development as well as during production failures, there is an urgent need to debug to identify the issue. Many a times the issue may lie with the ORM framework itself. This is an important consideration for any enterprise application.
3. Integration with JMX for runtime statistics
   If instrumenting the application during production under consideration, this is a must have feature for your ORM tool.

Essential Features

1. Ability to support multiple relationships
   These would include one-to-many, many-to-many and many-to-one relationships
2. Ability to support lazy loading
   This is important when you need to eagerly load a chain of nested objects. This feature is useful when underlying data store is not huge.
3. Ability to support sorting and pagination
   These features are a must for search based applications
4. Declarative security
   Authorizing different users to execute different queries can easily be achieved using this framework.
5. Support for Dynamic SQL
   For any non-trivial application dynamic SQL is a must

Conclusion
An enterprise architect can use the above criteria to evaluate the most suitable ORM framework for his application. Each of the criteria should be judged with respect to the application requirements. A scoring model which gives weightage to respective parameters and computes the final scores for each of the applicable ORM tools is the right procedure to use the above architectural framework.

• BAE Systems to Develop Mission-Planning Framework for U.S. Forces
• iWay Software's Adaptive Framework for SOA Now Certified as 'Ready for IBM WebSphere Business Integration Software'
• Research and Markets: Architecture-Independent Programming for Wireless Sensor Networks - New Automated, Application-Independent Methodology for Designing and Deploying Sensor Networks