Choosing a technology for data persistence

This excerpt from TechMetrix's report "Strategies for persistence of business objects in J2EE architectures" sets out the key factors to bear in mind when integrating object technologies into your information system.

This Content Component encountered an error


There are a number of approaches for integrating object-oriented technology into information systems, ranging from the use of simple technical objects to business-object-based architectures. However, enterprises today often lack the information they need to make the right choices.

First of all, it is important to understand the object paradigm so as to appreciate the benefits it brings to J2EE architectures. Several approaches can be used to integrate the object model into J2EE architectures.

The following diagram shows the areas in which the relational and object models can be comfortably used. The choice of database depends first of all on the type of data to be managed:

(See illustration)

  • For simple, table-based data (listing of invoices, enterprises, bank transactions...), the relational model is suitable, and SQL is a powerful and concise means of handling such data. If complex data must be associated with records (e.g. video associated with a company), object extensions to relational databases are satisfactory. Most of the data used in management computing is descriptive data, which is well suited to the relational model. This explains the success of RDBMSs in management IT. In such situations, the object approach adds needless complexity and the related tools are not as powerful as SQL.
  • For complex, dynamic-type data (3D maps, complex financial graphs, molecules, etc), the object-oriented approach is much more effective. It is no longer a question of manipulating the object data but, rather, the objects themselves, using more simple methods and queries. This explains why object databases are widespread in scientific domains and telecommunications, where the complexity of data makes the relational approach quite inadequate.

The examples above refer to extreme cases, where the choice between the relational and object approaches imposes itself fairly naturally. In all areas (flexibility, reliability, performances...), object and relational databases are generally effective within their own "comfort" zones.

However, there are some situations in which both approaches are possible. Development of e-business applications is one area in which choosing between the two approaches is far from easy. This is because the entities to be modeled are often fairly complex, as are the queries to data. The technological risk posed by object-oriented techniques often pushes companies to opt for a 100% relational approach.

Nonetheless, there are many factors that can encourage companies to incorporate object technologies into their new architectures. Use of new object languages (Java, C#...) will enable n-tiered architectures to be built, taking into consideration the plurality of user interfaces (Windows, HTML and so on) and the diversity of company resources (DBMS, document databases, email systems, directories, ERP and so on). Integrating object-oriented technology into the tier representing business entities is no doubt the most critical operation, and various approaches are available for this:

  • Retain the relational approach (or another, such as hierarchical...), but lose the advantages that could have been obtained from using business object modeling by separating processes from data.
  • Use a hybrid object-relational approach, which gives the advantages of business-object modeling and ensures compatibility with existing relational databases. This solution smoothly brings together old and new applications, not just in terms of architecture, but also as regards the skills invested in the relational approach (development, administration...).
  • Use an object database, which gives all the advantages of business object modeling but compromises previously-acquired skills and compatibility with existing relational databases.
Finally, in order for companies developing this type of architecture to choose between the solutions mentioned above, it is worth bearing the following factors in mind:

  • Performances
  • Transactional reliability
  • Productivity in application development
  • Mechanisms for integration with existing resources
  • Compliance with standards and portability.


Copyright 2002 TechMetrix Research. TechMetrix is a technology-oriented analyst firm focused on e-business application development needs. TechMetrix is also backed by its parent company, a European global system integrator - SQLI - with more than 800 developers in the field.

For More Information

  • For the Best Web Links for Web services, click here.
  • What do you think about this article? If you'd like to send feedback, you can E-mail the Editor.
  • Post your technical questions, or help out your peers by answering questions, in our Discussion Forums.
  • Ask the Experts! Our Web Services, XML, .NET, Java, EAI, and App Server gurus answer your toughest questions.

Dig deeper on Enterprise Application Integration (EAI)

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchSoftwareQuality

SearchCloudApplications

SearchAWS

TheServerSide

SearchWinDevelopment

Close