US007702649B1

(12) United States Patent

(10) Patent N0.: (45) Date of Patent:

Bresch et a]. (54)

OBJECT-RELATIONAL MAPPING SYSTEM

(75) Inventors: Stefan Bresch, Offenburg (DE); Michael Watzek, Berlin (DE);

Example ilnheritance Mapping Tutorial”, David Hayden Blog,

Christian Stork, Boenen (DE); Markus

http://davidhaydencom/blo g/dave/archive/ 2007/ 1 0/26/

Kuefer, Heidelberg (DE)

LINQToSQLInheritanceDiscrimin atorColumnExamplelnheritanceMappingTutorial.aspx, printed Aug. 12, 2008.

(73) Assignee: SAPAG, Walldorf (DE) Notice:

Subject to any disclaimer, the term of this patent is extended or adjusted under 35

pp.

1-3,

JavaTM 2 Platform Std. Ed. v1.4.2, “Interface Collection”, java.sun. com/j2se/.../collection.html, pp. 1- 10, printed on Jan. 21, 2009. JavaTM 2 Platform Std. Ed. v1.4.2, “Interface Map”, http://java/sun/

com/j2se/l .4.2/docs/api/java/util/ map.html, pp. 1-8, printed on Jan. 21, 2009.

U.S.C. 154(b) by 254 days.

(21) Appl.No.: 10/864,185 (22) Filed:

Apr. 20, 2010

Core Java Data Objects, Sameer Tyagi, Published Sep. 11, 2003; Chapter/Section: 2.4 pp. 1-4.* Ragae Ghaly and Krishna Kothapalli, “SAMS TeachYourselfEJB in 21 Days”, 2003, pp. 353-376. DAVID HAYDEN, “LINQ to SQL Discriminator Column

AND METHOD FOR GENERIC RELATIONSHIPS

(*)

US 7,702,649 B1

* cited by examiner

Jun. 8, 2004

Primary ExamineriShahid A Alam Assistant ExamineriAlex Gofman

(51)

(52) (58)

Int. Cl. G06F 7/00 G06F 17/00

(74) Attorney, Agent, or FirmiBlakely Sokoloff Taylor &

(2006.01) (2006.01)

Zafman LLP

US. Cl. ............................. .. 707/103 Y; 707/103 R Field of Classi?cation Search ............ .. 707/ 103 Y,

(57)

ABSTRACT

707/ 103 R

See application ?le for complete search history. (56)

A system and method are described for performing a mapping

between persistent data objects and a database. For example,

References Cited

a method according to one embodiment of the invention com

prises determining Whether an attribute having a generic type

U.S. PATENT DOCUMENTS 6,163,776 A

12/2000 PeriWal

6,163,781 A *

12/2000 Wess, Jr. ............... .. 707/103 X

is an instance of a persistent class; and if the attribute is an instance of a persistent class, then mapping the attribute to a

discriminator column holding the type associated With the attribute and further mapping the attribute to a reference

OTHER PUBLICATIONS Core Java Data Objects, Sameer Tyagi, Keiron McCammon, Michael

column holding a key associated With the attribute.

Vorburger, Heiko BobZin; Sep. 11, 2003; Chapter/ Section: Foreword, 1.3, 2.2, 2.3, 2.5, 3.9, 5.1, 9.5, 131*

17 Claims, 16 Drawing Sheets

EJB Container 101

Entity --'--

Bean

654

/ Data Operations \ persistent

State

Persistent

Data Object

Data Object

602 A

604

Persistence

Management H 6°°

Object/Relational Mapping

Relational Acct #

Phone it

00299282

408-720-8300

09889276

6511-3612222

Database 623

DB Table 660

Transaction

Manager 67°

US. Patent

Apr. 20, 2010

Sheet 3 0f 16

US 7,702,649 B1

h

$cN8m0o63n0 2m mm< 6$:5“2 639.62

[L

6Sncm20m 6E0n: 62890

E85690‘ 6$2806

L68"c3m2o1m 952 Hn:anoi worm

m.mE

US. Patent

Apr. 20, 2010

Sheet 10 0f 16

US 7,702,649 B1

F81.85%; can

NoPmkOQ.

EmEm mc.mE

2>>2m0 5vE20_1

@at

8w“om*2< N A W j \

m5E0

row

60.23

mEanmE

EPwOQ.

US. Patent

Apr. 20, 2010

:5/\

Sheet 11 0f 16

US 7,702,649 B1

AN

Now

mokw n

/

NJE DE Pom

q.91

51.3%; PomwOQ.

US. Patent

Apr. 20, 2010

Sheet 13 0f 16

US 7,702,649 B1

Fmodvwok No:

EoEm mc.mE

2>2>ox85 2m

NohwmPOQ 8w_out:< /\

2at

N A \ J /

Po:

60.83

m5

@532

FoPmOQ.

US. Patent

Apr. 20, 2010

Sheet 14 0f 16

Ewm cE cow < No5sN?

QmstEduwk

US 7,702,649 B1

2.mt

Pwocm>3? com

L /

$0

@5392

K/ 2Eo:__>m40uEax

FomO/EhZQ,

US. Patent

Apr. 20, 2010

Ewmc? o

on?

(itwomtE_

Sheet 15 0f 16

US 7,702,649 B1

com

z$82 3 . \

\

mzawo

m5

Fonw

_60.8 53

FoPmOQ’

non?

2.91

US. Patent

Apr. 20, 2010

Sheet 16 6f 16

12.5é4wom6uxczHg0;qm g:o9Em%Q.: J.6u5m/2N03; Emu3a0zH

US 7,702,649 B1

3.90

US 7,702,649 B1 1

2

OBJECT-RELATIONAL MAPPING SYSTEM AND METHOD FOR GENERIC RELATIONSHIPS

course of its existence). Moreover, multiple items of different persistent data may change as part of a single large scale “distributed transaction.”

BACKGROUND

FIG. 2 illustrates the manner in Which persistent data is managed in current J2EE environments. Session beans 255

257 comprise the high level Work?oW and business rules implemented by the application server 100. For example, in a

1. Field of the Invention This invention relates generally to the ?eld of data process ing systems. More particularly, the invention relates to a

customer relationship management (“CRM”) system, session beans de?ne the business operations to be performed on the underlying customer data (e.g., calculate average customer invoice dollars, plot the number of customers over a given

system and method for mapping persistent data objects to a database. 2. Description of the Related Art

timeframe, . . . etc).

Session beans typically execute a single task for a single client during a “session.” TWo versions of session beans exist: “stateless” session beans and “stateful” session beans. As its

Multi-Tier Enterprise Systems

name suggests, a stateless session bean interacts With a client

Java 2 Enterprise Edition (“J2EE”) is a speci?cation for

Without storing the current state of its interaction With the client. By contrast, a stateful session bean stores its state across multiple client interactions.

building and deploying distributed enterprise applications. Unlike traditional client-server systems, J2EE is based on a multi-tiered architecture in Which server side program code is

divided into several layers including a “presentation” layer

20

FIG. 1 illustrates an exemplary J 2EE application server 100 in Which the presentation layer is implemented as a Web container 111 and the business layer is implemented as an

25

Enterprise JavaBeans (“EJB”) container 101. Containers are

database 223. Typically, an entity bean 252 is mapped to a table 260 in the relational database and, as indicated in FIG. 2, each “instance” of the entity bean is typically mapped to a roW in the table (referred to generally as an “object-relational

mapping”). TWo different types of persistence may be de?ned

runtime environments Which provide standard common ser

for entity beans: “bean-managed persistence” and “container

vices 119, 109 to runtime components. For example, the Java Naming and Directory Interface (“JNDI”) is a service that

provides application components With methods for perform ing standard naming and directory services. Containers also

Entity beans are persistent objects Which represent data (e.g., customers, products, orders, . . . etc) stored Within a

and a “business logic” layer.

managed persistence.” With bean-managed persistence, the 30

entity bean designer must provide the code to access the underlying database (e.g., SQL Java and/or JDBC com

mands). By contrast, With container-managed persistence,

provide uni?ed access to enterprise information systems 117

the EJB container 101 manages the underlying calls to the database.

such as relational databases through the Java Database Con

nectivity (“JDBC”) service, and legacy computer systems through the J 2EE ConnectorArchitecture (“J CA”) service. In

Entity Bean Deployment

addition, containers provide a declarative mechanism for

con?guring application components at deployment time through the use of deployment descriptors (described in greater detail beloW). As illustrated in FIG. 1, each layer of the J 2EE architecture includes multiple containers. The Web container 111, for example, is itself comprised of a servlet container 115 for processing servlets and a Java Server Pages (“J SP”) container

A “deployment descriptor” is an XML ?le (named “ejb jar.xml”) that describes hoW entity beans are deployed Within the J2EE application server 100. For each CMP entity bean, 40

116 for processing Java server pages. The EJ B container 101

includes three different containers for supporting three dif ferent types of enterprise Java beans: a session bean container 105 for session beans, an entity bean container 106 for entity

45

beans may be de?ned as “one-to-one” Where each entity bean

50

is associated With a single instance of another entity bean, “one-to-many” Where each entity bean is associated With many instances of another entity bean, or “many-to-many” Where entity bean instances may be related to multiple instances of each other. An exemplary object model of three entity beans is illus trated in FIG. 3 and an exemplary deployment descriptor describing the three entity beans is illustrated in FIGS. 411-0. The entity beans include a product entity bean 303 represent

beans, and a message driven bean container 107 for message driven beans. A more detailed description of J 2EE containers and J 2EE services can be found in RAGAE GHALY AND KRISHNA

KOTHAPALLI, SAMS TEACH YOURSELF EJB IN 21 DAYS (2003)

(see, e.g., pages 353-376). Persistence and Enterprise Java Beans 55

The information systems of a modern day enterprise (such as a corporation or government institution) are often respon

sible for managing and performing automated tasks upon large amounts of data. Persistent data is that data that “exists”

for extended periods of time (i.e., it “persists”). Persistent

the deployment descriptor de?nes “persistent ?elds” Which represent and store a single unit of data, and “relationship” ?elds Which represent and store references to other entity beans. Relationship ?elds are analogous to foreign keys used in relational database tables. Relationships betWeen entity

60

ing one or more products, an order entity bean 301 represent ing a business order and a customer entity bean 302 repre senting a customer. As indicated in FIG. 3, a many-to-many

relationship exists betWeen the product bean 303 and the order bean 301 (i.e., many different product may be used in many different orders). Similarly, a one-to-many relationship

data is typically stored in a database so that it can be accessed as needed over the course of its existence. Here, complex

exists betWeen the customer bean 302 and the order bean 301

database softWare (e.g., such as DB2, Oracle, and SQL Server) is often used to read the data and perhaps perform

The container-managed persistence (“CMP”) ?elds of the product bean 303 include product Name, Product ID, and

various intelligent functions With it. Frequently, persistent data can change over the course of its existence (e.g., by executing a series of reads and Writes to the data over the

(i.e., an individual customer may make multiple orders).

65

Price (identifying the name product identi?cation code and

price, respectively, of each product). The CMP ?elds for the order bean 301 include Order ID, Order Date, Credit

US 7,702,649 B1 4

3

FIGS. 4a-c illustrates an exemplary deployment descriptor

Approved (indicating Whether the user’s credit card company approved the order) and Order Status; and the CMP ?elds for the customer bean 302 include social security number (SSN),

employed Within a J 2EE environment. FIG. 5 illustrates a clustered server architecture on Which

Age, First Name and Last Name of the customer.

embodiments of the invention are implemented. FIG. 6 illustrates a persistence management architecture on Which embodiments of the invention may be implemented. FIG. 7 illustrates a state transition table employed by one

The deployment descriptor illustrated in FIGS. 4a-c includes separate sections 401-403 representing and describ ing the CMP ?elds for each entity bean 301-303, respectively. For example, section 401 includes four entries 410-413 (iden

embodiment of the persistent management layer.

ti?ed by the XML tags) identifying each of the order entity bean’s CMP ?elds (i.e., Order ID, Order Date, Credit Approved, and Order Status). Entity bean sections

FIG. 8 illustrates a one-to-many bidirectional mapping employed in one embodiment of the invention. FIG. 9 illustrates a many-to-many bidirectional mapping employed in one embodiment of the invention. FIG. 10 illustrates a one-to-one bidirectional mapping employed in one embodiment of the invention. FIG. 11 illustrates an embodiment of the invention Where

402-403 include similar entries identifying CMP ?elds. In addition, for each entity bean, one particular CMP ?eld is

identi?ed as the primary key ?eld using the tag 414-416 (e.g., Order ID for the order bean 301). A section 405 of the deployment descrip tor (see FIG. 4b) de?nes the relationships betWeen each of the entity beans 301-303. Each entity bean relationship is de?ned under a separate tag 406, 407. For example, the one-to-many relationship betWeen the order bean 301 and the customer bean 302 is described by setting the tag 430 associated With the orderbean 301 to “many” and setting the tag 431 associated With the cus

there is one-to-many relationship betWeen classes. FIG. 12 illustrates one embodiment of the invention in Which a class contains a reference to an interface.

FIG. 13 illustrates one embodiment of the invention Which 20

FIG. 14 illustrates columns employed in one embodiment of the invention and associated JDBC types.

tomer bean 302 to “one.” Similar descriptions are provided

under tag 407 to de?ne the many-to-many relationship betWeen the order bean 3 01 and the product bean

employs a join table.

25

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

Described beloW is a system and method for mapping generic persistent data types to a relational database.

303.

Throughout the description, for the purposes of explanation,

Java Data Objects 30

numerous speci?c details are set forth in order to provide a

object persistence. The java.io.SerialiZable interface, for

thorough understanding of the present invention. It Will be apparent, hoWever, to one skilled in the art that the present

example, provides class programmers a Way to explicitly save objects to an output stream (e.g., Writing the obj ect’s ?elds to a ?at ?le on a local disk). By contrast, JDBC and SQLJ

invention may be practiced Without some of these speci?c details. In other instances, Well-knoWn structures and devices are shoWn in block diagram form to avoid obscuring the

Several techniques may be used to provide support for

35

provide mechanisms for storing and retrieving data objects

underlying principles of the present invention.

into a database, in addition to concurrency controls through

Note that in this detailed description, references to “one

transactions. HoWever, these techniques all require that the class programmer either be responsible for handling the

embodiment” or “an embodiment” mean that the feature

underlying details of persistence management (or learn a neW language to interface With the back end data store).

being referred to is included in at least one embodiment of the 40

The Java Data Objects (J DO) speci?cation addresses these

invention. Moreover, separate references to “one embodi ment” in this description do not necessarily refer to the same embodiment; hoWever, neither are such embodiments mutu

issues by providing a higher level abstraction, referred to

ally exclusive, unless so stated, and except as Will be readily

generally as “transparent persistence.” That is, the persistence

apparent to those skilled in the art. Thus, the invention can include any variety of combinations and/or integrations of the embodiments described herein.

of data objects can be made automatic and all logic for pro

45

cessing persistent objects may be expressed in pure Java language. In addition to shielding the class developer from the details of the underlying persistence methods, J DO also acts as a standard layer betWeen the application program (e.g., the EJBs) and any back-end data storage, Whether it be a data base, ?le system, or other non-volatile memory. Applications utiliZing the JDO interface may automatically plug in to any data store Which provides a JDO implementation, thereby

improving portability and increasing the longevity of the application code.

An Exemplary Application Server Architecture 50

A system architecture according to one embodiment of the invention is illustrated in FIG. 5. The architecture includes a

central services instance 500 and a plurality of application server instances 510, 520. As used herein, the application server instances, 510 and 520, each include a group of server 55

nodes 514, 516, 518 and 524, 526, 528, respectively, and a

dispatcher 512, 222, respectively. The central services BRIEF DESCRIPTION OF THE DRAWINGS

A better understanding of the present invention can be

obtained from the folloWing detailed description in conjunc tion With the folloWing draWings, in Which: FIG. 1 illustrates several layers Within a prior art J2EE architecture. FIG. 2 illustrates an object/relational mapping betWeen an entity bean and a relational database table.

FIG. 3 illustrates an object model of three exemplary entity beans.

60

instance 500 includes a locking service 502 and a messaging service 504. The combination of all of the application instances 510, 520 and the central services instance 500 is referred to herein as a “cluster.” Although the folloWing description Will focus solely on instance 510 for the purpose

of explanation, the same principles apply to other instances such as instance 520.

The server nodes 514, 516, 518 Within instance 510 are 65

used to implement business logic and presentation logic. Each of the server nodes 514, 516, 518 Within a particular instance 510 may be con?gured With a redundant set of appli

US 7,702,649 B1 5

6

cation logic and associated data. In one embodiment, the dispatcher 512 distributes service requests from clients to one

data stored Within a database 623. For example, in one

embodiment, each persistent data object 602, 604 contains

or more ofthe server nodes 514, 516, 518 based on the load on

data from a roW in a database table 660.

each of the servers. For example, in one embodiment, the

In a J2EE environment, the EJ B containers 101 on the

dispatcher 512 implements a round-robin policy of distribut

various server nodes 514, 516, 518, 524, 526, 528, interact

ing service requests. Which support Enterprise Java Bean (“EJ B”) components and

With the persistence manager 600 through a Well-de?ned interface. In one embodiment, for every container-managed entity bean instance 652-653 activated by the EJ B Container 101 in response to a client request, a corresponding persistent

EJB containers (at the business layer) and Servlets and Java

data object 602, 604 is created by the persistence manager

In the description that folloWs, the server nodes 514, 516, 518 are Java 2 Enterprise Edition (“J2EE”) server nodes

Server Pages (“J SP”) (at the presentation layer). Of course,

600. Unlike a standard J2EE con?guration in Which each of

the embodiments of the invention described herein may be

the entity bean instances contains persistent data from the database, the entity bean instances 652-653 illustrated in FIG. 6 are comprised of only the business methods that manipulate

implemented in the context of various different softWare plat

forms including, by Way of example, Microsoft .NET plat forms and/or the Advanced Business Application Program

the persistent data (e.g., using abstract get/ set methods), and the persistent data itself is stored and managed by the persis

ming (“ABAP”) platforms developed by SAP AG, the assignee of the present application. In one embodiment, communication and synchronization betWeen each of the instances 510, 520 is enabled via the central services instance 500. As illustrated in FIG. 5, the central services instance 500 includes a messaging service 504 and a locking service 502. The message service 504

tence manager 600. In one embodiment, these methods are

provided as part of the EJ B Container 101.

A persistence manager 600 and associated persistent data 20

on each server node. While in memory, the data Within the

persistent data objects 602, 604 may be continually modi?ed

alloWs each of the servers Within each of the instances to communicate and stay synchroniZed With one another via a

message passing protocol. For example, messages from one

in response to business transactions. At some point, hoWever, the persistent data must be committed to the database. As 25

server may be broadcast to all other servers Within the cluster

via the messaging service 504. Alternatively, messages may be addressed directly to speci?c servers Within the cluster (i.e., rather than being broadcast to all servers). The term “messages” is used broadly here to refer to any type of data communication betWeen the server nodes and dispatchers in the cluster. In one embodiment, the locking service 502 disables

30

insert, update, or delete operation) 35

In one embodiment, the messaging service 504 and the 40

ers. HoWever, the messaging service 504 and the locking service 502 may be implemented on a single server or across

forth in the remaining roWs of columns 702, 703 and 704. In one embodiment, the possible values for a persistent object state are as folloWs:

nicating With the messaging service 504; and a con?guration

512, 522 may be equipped With equivalent lock managers, cluster managers and con?guration managers.

data With the database. The initial state of the persistent data object is set forth in column 701; the operations to be per formed on the persistent data object are set forth in the top roW of columns 702, 703 and 704; and the resulting state of the

persistent data objects folloWing each of the operations is set 45

includes a lock manager 540, 550 for communicating With the locking service 502; a cluster manager 542, 552 for commu

manager 544, 554 for communicating With a central database 530 (e.g., to store/retrieve data as described herein). Although the lock manager 540, 550, cluster manager 542, 552 and con?guration manager 544, 554 are illustrated only With respect to server nodes 518 and 528 in FIG. 5, each of the server nodes 514, 516, 524 and 526 and/or on the dispatchers

In one embodiment, the persistence manager 600 manages

the state properties 601, 603 associated With each persistent data object 602, 604 according to the state transition table illustrated in FIG. 7. The state of a persistent object implies the operation that must be executed in order to synchroniZe its

dispatchers.

multiple servers While still complying With the underlying principles of the invention. As illustrated in FIG. 5, each server node (e.g., 518, 528)

With each persistent data object 602, 604, respectively. The state property 601, 603 identi?es the database operation to be executed When the data contained Within the persistent data object 602, 604 is committed to the database (e.g., via an

the locking service 502 enables a distributed caching archi tecture in Which copies of data are cached locally at servers/

locking service 502 are each implemented on dedicated serv

such, in one embodiment of the invention, the persistence manager 600 employs techniques to ensure that the correct database operations are performed When it is time to commit the data to the database. Speci?cally, in one embodiment, the persistence manager 600 associates a state property 601, 603

access to (i.e., locks) certain speci?ed portions of data and/or program code stored Within a central database 530. Moreover,

objects 602, 604 may be maintained as in an in-memory cache

50

DEFAULTiThe default property is the initial property of the persistent data object. All persistent data objects are in this state before they are affected by a transaction. If this state is preserved until the end of the transaction, this means that the

data represented by the object is consistent, that this data is the 55

same as in the database, and no operation is performed in the database.

UPDATEDiThe “updated” state indicates that the persis tent data object has been changed. As such, the data Within the

database represented by the persistent data object must be

Embodiments of a Persistence Management Layer

synchroniZed With an “Update” query. CREATEDiThe “create” state identi?es a neWly-created

The embodiments of the invention described herein

persistent data object. As such, the database must be synchro

improve the portability and extensibility of enterprise appli cations by separating the pure business logic (e.g., entity

niZed With a “Create” query (e.g., a neW roW Will be added to

beans and session beans in a J2EE environment) from persis

the database).

tent data objects. FIG. 6 illustrates one embodiment Which includes a persistence manager 600 for managing a plurality

of persistent data objects 602, 604. The persistent data objects 602, 604 provide an in-memory representation of persistent

REMOVEDiThe “remove” state indicates that the per 65

sistent data object has been deleted. As such, the database must be synchroniZed With a “Remove” query (e.g., removing a roW in the database).