Architecture

Maybe you expect the UML-design sketch of an O/R access layer now. Sorry. Before we come to this we have to talk about design forces and requirements for an object/relational access layer. We follow the line that we will first explain what we need to build before we explain how you can build it. The latter will happen in the section on general architecture for o/r layers and also OODBMS.

Forces Driving the Design of O/R Access Layers

The following set of forces that influence the design of an o/r access layer  is adapted from Accessing Relational Databases [Kel+98a]. There are only a few more forces here than for pure relational access layers:

• Functionality versus cost: Besides the mandatory features of object-oriented database systems, listed below there are also a lot of optional features. Even some of the mandatory features are known to be expensive to implement, and some of the optional ones are even harder. If you are building an access layer you should therefore balance the features you'd like to incorporate into an object/relational access layer with the budget your users are willing to spend. Today you get much more bang for the buck by either using open source products or "stealing" ideas from them. Why invent, if you can also copy. If you intend to do so, have a look at the mass of products that are available today.
  
• Separation of concerns versus cost: Database programming is complex and so are object-oriented programming languages. Mapping one concept to the other will add up to more than just the combined complexity. The easiest way is to separate the application programming from the database programming and to separate the object-oriented database aspects from the relational database aspects. You are then able to exploit well-known patterns for each of the problem domains. The cost of separated layers has to pay off with increased maintainability and easier performance tuning. Today with reflection in place e.g. in Java it is possible to make persistence almost invisible in the domain classes.
  
• Performance: Database tuning, locking strategies and clever caching are crucial to achieve acceptable performance of a business information system. Since a database is several orders of magnitude slower than the main processor running the o-o language you map, tuning will concentrate on database access. Tuning is an iterative process. To optimize database access you may change the access layer architecture and behavior, the physical parameters of the storage system, as well as the table layout, or the API to access the database. It's a good idea to remember XP here. Build the simplest thing that might possibly work - and if it is not fast enough you can still spend effort on refactoring it.
  
• Flexibility versus complexity: Since database tuning is crucial, you want to have an encapsulation of the database that allows changes to the underlying data model while your upper layers of software (the application kernel and most of the access layer) remain untouched. Unfortunately, the more flexible a system is, the more complex it will be.
  
• Legacy systems: You seldom develop business information systems from scratch. Instead, you have to connect to legacy systems which you are not allowed to touch. Usually you can not supersede the complete legacy code, because big bang strategies are risky and expensive, but, the structure of legacy data rarely fits your needs - if it has any structure. You may also have to bridge several generations of database technologies. To keep your application maintainable you have to encapsulate the legacy access. This is a particular strong force during reengineering projects.
  
• Application style: Besides database driven business information systems there are other types of information systems. Using a relational database as persistence mechanism for some of these might end in disaster. Some examples are.
  
• CAD applications: CAD applications are used to manipulate large sets of very complex, interrelated objects. Transactions are long. A CAD designer typically checks out a design, works on it for hours and then checks it back into some data store. Building such applications on top of a relational database using an object/relational database mapping is doomed to fail. Simple pointer dereferencing in working storage is faster by a factor 10⁶ than joins. Relational databases are not intended for very long transactions with a zero collision rate.
  
• CASE Tools: CASE tools have characteristics similar to CAD systems. IBM’s negative experience with the AD/Cycle repository is a prominent example of what happens if such applications are implemented on top of a relational database.
  
• Any check in / check-out persistence applications: The above examples can be generalized to applications that use complex, interrelated objects, allow direct manipulation and allow the user to check them out of a database for a longer period of time. Such systems should be built using non-relational data stores.

Check you do not build one of the above applications before you map objects to relations.

Requirements for Object/Relational Access Layers

Given that you have to use a relational database and given that you want a fully object-oriented application kernel it is good to have a list of typical functionality for an object-oriented database. The Object-Oriented Database System Manifesto [Atk+89] (direct link) contains a very comprehensive list of the functionality you might want to provide (see Table 1) with your object/relational access layer.

Table 1: Core responsibilities of an Object-oriented Database Management System

Most of the functionality listed in Table 1 comes with your object-oriented programming language (like 1, 3, 4, 5, 6, 7, 8). The challenge is to make your object-oriented programming language’s objects persistent, giving them the ability to survive the termination of the actual process and to be used again in other (also in parallel) processes.

Therefore the other requirements are typical requirements that you find for databases (like 9, 10, 11, 12,13). See any database book for an explanation, e.g. [Dat95].

Two Layer Architecture

The main pattern for object/relational access layers is Two Layer Persistency Subsystem. But at the top level you will find other patterns that are also concerned with coarse structure. Follow the hot spots on the Roadmap in order to find the right source..

Roadmap

Figure 4: Local Roadmap: Architecting an Object/Relational Access Layer

Pattern List

• Layered Architecture for Business Systems: What is a good overall architecture for Business Systems? See [Ren+97] (download it) for a discussion in pattern form and [Bus+96] for a general discussion of layered architectures (Layers).
• Two Layer Persistence Subsystem: What is a good structure for a persistence subsystem?
• Physical Views: How do you provide an easy to use interface to your physical database tables? See [Kel+98a] and also the Query Objects Pattern in [Bra+96].
• Host Access: How do you link you database access layer to a transaction based host database server?

Pattern: Two Layer Persistency Subsystem

Problem

What is good way to structure an object-oriented database or an object/relational access layer?

Forces

Remember the above discussion on Separation of concerns versus cost: Database programming is complex, storage subsystems are complex but they are known abstractions. Object-oriented programming languages are also proven concepts. Both have enough complexity. Mapping one concept to the other and not dividing into further subsystems could easily sum up to a nightmare of complexity. The easiest way is to separate the concepts of object-orientation from those of database programming and to separate the object-oriented database aspects from the relational database aspects. You are then able to exploit well- known patterns for each of the problem domains. The cost of separated layers has to pay off with increased maintainability and easier performance tuning.

Application style is another force. You should be able to adapt you object persistence subsystem to the different application styles mentioned above. It makes a great difference, whether you intend to write a transaction oriented system or a system that can best be described with check in/check out persistence.

Finally the possible integration of legacy data sources will have its effects on you design.

Solution

Build your system as two subsystems that form a layered structure. The upper layer, called the object layer, encapsulates the concepts of object-orientation while the lower layer, called the storage manager, offers a high level interface on top of your physical storage devices or file system. A relational database in this context is just another physical storage device.

Structure

Figure 5: Two Layer Structure of a Persistency Subsystem for
Object-Oriented Programming Languages (o-o programming languages)

Assign the following responsibilities from The Object-Oriented Database System Manifesto [Atk+89] to the layers.

Object Layer:

The object layer encapsulates the concepts of object orientation. It has the following responsibilities: (1) Complex Objects, (2) Object Identity, (3) Encapsulation, (4) Types and Classes, (5) Class or Type Hierarchies, (6) Overriding, overloading and late binding, (7) Computational Completeness, (8) Extensibility, (13) Ad Hoc Query Facility. This is the object-oriented programming languages part of the requirements listed in Table 1.

Storage Manager:

The Storage Manager provides an interface to a Physical Storage Subsystem. It has the following responsibilities: (9) Persistence, (10) Secondary storage management, (11) Concurrency, (12) Recovery, (13) Ad Hoc Query Facility. This is the database part of the requirements listed in Table 1. The only exception is the "Ad Hoc Query Facility". The Ad Hoc Query Facility is a database concept that you wrap at the level of your object-oriented language in order to offer your user the equivalent of SQL. Therefore you have to deal with some form of Object SQL (also called Object Query Language (OQL) [ODMG93]) in both layers.

This discussion could lead to some form of abstract pattern. Whenever you have two paradigms that need to be mapped on one another, you can come up with an architecture that consists of two layers. These layers contain the respective abstractions of the two paradigms, and the upper layer (the paradigm you want to map onto another) needs some code to call the lower layer – this code is mostly in the broker patterns (see Moving Attributes to and from the Tuple Layer)

Consequences

Manageability and complexity: This approach breaks the problem down into manageable parts by cutting it into two halves – and one of these, the storage manager, is not a new problem but a kind of component with a long lasting design history.

Application Style: You can adapt your persistence subsystem to different application styles by plugging in different storage managers. The need to adapt to transactional legacy systems will influence your storage manager but not your object layer.

Variants

An object/relational access layer is a variant of an object-oriented database. An architectural sketch from POET makes this quite evident. POET is an object-oriented database that uses a relational database (plus an access layer) as its storage subsystem.



If you do not use an object-oriented database with a relational database as its storage manager you have to build an object/relational access layer. For the rest of the paper we will use the term tuple layer instead of storage subsystem as we use relational databases to store our objects.

 



Figure 6: Two Layer Structure for an Object/relational access Layer

Related Patterns

We have used the concepts of Layers [Bus+96] here. All the other patterns in this paper are further solutions to the problems of how to build such an access layer.

Known Uses

Most object-oriented databases and object/relational access layers are built this way. We have already cited POET [POE97] as an arbitrary example. TopLink is an example that uses the pattern in a object/relational access layer product [TOP97a,TOP97b]. There are many project solutions, that follow the same architecture [Bar+95, Hah+95, Kel+98b, Sta+97, Wal+95]. Another use of the architecture can be found in [Hei98]. Heinckiens distinguishes an object layer, a database layer and brokers between the two layers, which he calls Impedance Mismatch Resolvers.

-> on to the Object Layer

-> up to the Contents Page