Revision as of 10:46, 27 November 2007

EclipseLink Architecture

Abstract

This document gives an overview of the EclipseLink architecture. It documents the components and functionality of the EclipseLink product. Its purpose is to give EclipseLink developers an overview and understanding of the EclipseLink architecture and how it evolved to where it is today. Its focus is from the internal technical perspective. This is NOT a user document.

EclipseLink was originally an object-relational mapping runtime. A class library that enables Java developers to map their business object model onto a relational database schema. EclipseLink provides object-level access to the objects stored in a relational database.

EclipseLink also provides EIS, object-relational data-type, XML, WebSevice, and SDO components. These components reuse at a minimum the mapping functionality of the core product.

EclipseLink provides a rich feature set to facilitate:

• Decoupling/flexibility of the object and data models
• Object level processing, data transparency
• Usability
• High performance, scalability, concurrency
• Adherence to standards
• Portability

Code Version

EclipseLink 1.0M1

Overview

Introduction

EclipseLink was first developed through consulting engagements in the early 1990’s in the Smalltalk language. It was developed to meet the needs of object-oriented applications that needed to store and access their data from relational databases. Before its first release it was refactored through several client engagements. It basic design has not changed significantly from the initial release in that its architecture is object-oriented, non-intrusive, plugable and meta-model driven.

A rough timeline that includes the major enhancements and refactoring to the product architecture follows:

• The Object People
  • TopLink Smalltalk 1.0 – Descriptors, Mappings, Session, Accessor (ODBC), Cache, Indirection (proxy), Expressions (arrays), reflection
  • TopLink Smalltalk 2.0 – Expressions (block), TrackingUpdateManager (backup-clones), prototype of Builder UI
  • TopLink Smalltalk 2.1 - UnitOfWork (edit originals, backup-clones track changes)
  • TopLink Smalltalk 4.0 – QueryFramework, SessionBroker
  • TopLink Java 1.0 – Descriptors, Mappings, Session, Accessor (JDBC), Cache, QueryFramework, Expressions (tree), UnitOfWork (edit clones), Builder UI (Smalltalk, INI meta-data), Indirection (value-holders), reflection
  • TopLink 2.0 – ServerSession, Session API interfaces, RemoteSession, JTS, SessionBroker
  • TopLink 2.5 – EJB-CMP 1.0
• WebGain
  • TopLink 3.0 – Cache Synch, SDK, XML, Mapping Workbench UI (Java, XML meta-data), EJB-CMP 1.1, JDO
  • TopLink 4.0 – WebGain package rename, CMP 2.0, EJB-QL, internationalization, code generation
• Oracle
  • TopLink 9.0.3 – Oracle package rename
  • TopLink 9.0.4 - Sequencing redesign, JDeveloper UI (+MW)
  • TopLink 10.1.3 - JPA preview, EIS, XML (OX), JAXB 1.0, JDeveloper UI, RCM cache coordination, change tracking, weaving
  • TopLink 11 - JPA 1.0, JPQL, JAXB 2.0, SDO, DBWS, Eclipse Dali UI (+MW, JDev)
• Eclipse
  • EclipseLink 1.0M1 - Eclipse package rename, open source

Design Approach

EclipseLink's design approach is object-oriented, non-intrusive, plugable and meta-model driven.

Object oriented:

• Descriptor and mappings are EclipseLink's object model, there is a class for each type of mapping
• Query framework is querying object model, there is a class for each type of database interaction

Non-intrusive:

• Avoid object model and data model requirements

Pluggable:

• Abstract classes used for most functionality, allows easy extension through subclassing (mappings, queries, accessors, platforms, query mechanisms, sessions, transaction controllers)

Meta-model:

• Mapping information is stored in XML or annotations and read in at runtime into a descriptor/mapping meta-model, instead of being used to generate functional code.

Components

Component Overview

The main logical components of EclipseLink are:

• Core - Core descriptor and mapping functionality and generic data access.
• Relational - Relational descriptor and mappings, JDBC data access.
• OR data-type - Object-relational data-type descriptor and mappings.
• Oracle - Oracle database extensions.
• EIS - Enterprise Information Systems descriptor and mappings, JCA data access and adapters.
• XML - XML descriptor and mappings, XML data access.
• JAXB - Java API for XML Binding facade and schema processing.
• JPA - Java Persistence API facade and meta-data processing.
• SDO - Service Data Objects implementation.
• DBWS - Database web services processing.

The diagram shows a somewhat idealized representation of the components and their dependencies. This differs slightly from the component organization in Eclipse SVN, and the compile time dependencies. There are some dependencies between the components that require some of the components to be coupled together. Also some components are not significant enough to warrant they own SVN component.

Code Layout

Interfaces

EclipseLink makes use of interfaces to define public API, and to define internal API for certain components. Abstract classes are also used in several places to define internal API. The usage of internal interfaces and abstract classes allows the architecture to be extensible and new functionality easily added.

Core Interfaces

API Interfaces:

• Session – public session API
• DatabaseSession – public 2-tier CRUD session API
• Server – public server session API
• UnitOfWork – public unit of work API
• ChangeSets – public change sets API
• ValueHolderInterface – basic value holder interface
• DescriptorEventListener – event interface
• SessionEventListener – event interface

Internal Interfaces:

• WrapperPolicy – used for EJB2 EntityBean remote/local un/wrapping of bean instance/reference
• OptimisticLockingPolicy – allows set of locking policies
• Call – abstraction for SQL and non-relation data source interactions
• Accessor – abstraction for JDBC and non-relational data source access
• Connector – login abstraction for different methods of data source connection
• Login – abstraction of login for relational and non-relational sessions
• Profiler – abstraction for performance monitoring

Abstract classes:

• AbstractSession – generic session behavior (query execution, caching)
• DatabaseMapping – generic mapping, cloning, comparing behavoir
• DatabaseQuery – generic data source interaction execution
• DatabaseQueryMechanism – allows queries to support different execution types (JPQL, expression, SQL, calls)
• Expression – generic SQL generation, normalization, tree walking
• IdentityMap – generic caching behavoir
• IndirectionPolicy – generic indirection manipulation
• DatabaseValueHolder - generic deferred instantiation
• ContainerPolicy – generic collection manipulation
• RemoteConnection – communication independent remote abstraction
• ChangeRecord – generic change merging
• AbstractTransactionController – abstraction of external (JTA) transaction integration
• AbstractSynchronizationListener - abstraction of external (JTA) transaction integration
• QueryKey – generic query alias representation

Data Structures

Algorithms

Tools