Object Persistence: Beyond Object Oriented Databases

Read an Excerpt

PREFACE: Introduction
The Object Management Group (OMG) has adopted a specification for the Persistent Object Service (POS). The specification provides an industry standard for writing datastore independent code for storing and restoring objects and for plugging existing datastores into an object storage framework. The adoption of the POS standard by this large industry consortium will likely have a major impact on the way object-oriented storage systems are designed and used in the next few years.

This standard will impact most data storage industries. Traditional database vendors will find they can participate as first-class object datastores. Object-oriented databases will be reexamining their interfaces for conformance to this standard. The object-oriented community will start moving to an object-centric view of persistence rather than a data-centric view of datastores.

The POS (Persistent Object Service) specification provides important benefits. It allows object implementors to create objects that can be stored to any datastore, in any format. It allows clients to use a single interface regardless of whether the object is stored in file systems, relational databases, object-oriented databases, or other datastores. It allows existing corporate-centric datastores, such as relational databases, to be used as first-class object stores.

The standard also defines the components that must be implemented by datastore vendors to support the storage of objects. This book describes work in progress for support of the OMG standard with plug compatibility for DB2(tm), Stream files, and other datastores. This book describes the interfaces used for storingand restoring objects, and looks at code that implements the concept of datastore independence.

In short, this book gives you all the background you need to understand the Persistent Object Service standard and tells you everything you need to know about how this standard works. This book even tells you when the standard doesn't work and what might be done to fix it.

This book is for you, whether you are an end user running applications that store objects, an applications developer implementing persistent objects, a datastore provider wanting to plug into this service, or just a student trying to keep up with the latest theories on how to view object persistence.

Historical Perspective
Software, like many things, has undergone a huge transformation in the last twenty-five years. In the early 70s, programs were considered state of the art if they used some higher-level language. Our development techniques, however, were still firmly rooted in Assembly Language. A program to manage, say, a hospital emergency room, would contain code like the following:


pptr = 0;
n = n1;
100 if (n == 0) goto 1000;
if (n->type == "P") goto 200;
if (n->type == "S") goto 300; R<> 200 if (n->phys.ptype == ntype) goto 500
goto 400;
300 if (n->spec.ptype == ntype) goto 500
400 n = n->next;
goto 100;
500 if (n->type == "P") pptr = n->phys;
goto 1000;
if (n->type == "S") pptr = n->spec;
1000

By the 80s, we discovered structured programming. Gotos were out. Indented logic branches were in. Our emergency room code would now look like the following.
n = n1;
while (!n) {
if (n->type == "P") &&
(n->phys.ptype == ntype)
pptr = n->phys;
else if
(n->type == "S") &&
(n->spec.ptype == ntype)
pptr = n->spec;
n = n->next;
}
Structured programming promised to solve the software crisis by creating small, focused modules, which could be reused in many different programming situations. Unfortunately, the modules were invariably dependent on specific data types that were defined external to the modules. The modules encapsulated behavior, but not data. When programmers made minor changes to these data structures, the modules were no longer useful.

Programmers sought a technique for encapsulating both behavior and data structures. Thus were born objects. Our code started getting much more readable. By the late 80s, our hospital management program evolved to a fairly simple main program, which would now contain the following:
physician =
getNextAvailablePhysician(WaitingRoom, Cardiologist);

This main program would make use of class libraries containing method implementations, such as:
Physician WaitingRoom::
getNextAvailablePhysician (specialty_needed)
{
return (findByKey(specialty_needed));
}

It was starting to look as if the age of software maintainability and reuse had actually arrived.

Unfortunately, what looked like a good idea in the academic world quickly ran into real-world problems. It is true that we had encapsulated both data and behavior, allowing both to be managed and extended as a coherent package. In the real world, data had to be stored, and existing data had to be read in. Our make-believe world of simple, encapsulated object methods quickly began to deteriorate. Our methods started getting ugly.
Physician WaitingRoom::
getNextAvailablePhysician (specialty_needed)
{
Physician phys;
EXEC SQL INCLUDE SQLCA;
EXEC SQL BEGIN DECLARE SECTION;
char Name100;
short Age;
EXEC SQL END DECLARE SECTION;
EXEC SQL SELECT NAME, AGE
INTO :Name, :Age
WHERE SPECIALITY = specialty_needed;
if (sqlca ->sqlcode == NONE_FOUND) return NULL;
if (Speciality == NULL)
phys = new physician;
else {
phys = new specialist;
setSpeciality(phys, speciality_needed);
}
setName(phys, Name);
setAge(phys, Age);
}

Object-oriented database vendors gave us their solution. Simply throw away your terabytes of existing data, rewrite your millions of lines of code, bring your corporation to a halt for ten years while you update your system, and your problems will be solved!

Software was undergoing other changes as well. Problem domains were becoming more distributed. Our concept of process began as a deck of punch cards, evolved to executable programs, to multiple processes on a machine communicating with each other, to processes communicating over a homogenous network, to processes communicating over a corporate-wide network consisting of many manufacturers' machines.

Watching the enormous advances in the Internet over the last few years, it is clear that we have just barely begun to understand the concept of distributed software.

So where is this driving the industry? The next generation of software will consist of components tied into a huge variety of database products. These components will be distributed over mega-networks that will literally extend throughout the known galaxy. If we think software was complicated before, we clearly ain't seen nothin' yet.

If objects are the answer, how do we get our objects back to a manageable state? How do we create objects that can be tied into any database, that can be distributed over any network, that can cooperate with other objects written in any programming language? These are the fundamental problems that must be solved if object-oriented programming will be of any value into the twenty-first century.
The OMG
Over 600 companies are members of OMG (Object Management Group) located in Framingham, Massachusetts. The purpose of the OMG is to create standards that will enable a distributed objects components industry. These standards range from low level, describing the interfaces for the underlying plumbing, to mid level, describing basic services object implementors can assume exist independent of their implementations, to high level, describing how objects within applications interact.

The members of OMG range from the giants of the hardware and software industry to tiny companies barely starting up. Members include companies seeking to dominate entire industries; companies seeking toeholds in developing markets; companies that want to find a niche developing software components; and companies desperately wanting to purchase existing components instead of continually having to write their own. Some of the OMG members are so large they have multiple representatives at the OMG, each representing a different, and sometimes competing, interest within the same company. Others are so small that sending a single representative to a few OMG meetings a year is a huge financial commitment.

Attendees at OMG meetings often include a who's who of the object industry. These people each have company loyalties, strong personal beliefs, and shifting allegiances within OMG. As one can imagine, attempts to reach consensus with such a group are well sprinkled with politics, personalities, and philosophical conflicts.

In the face of this daunting challenge, the OMG has done a remarkable job of achieving agreement on issues ranging from basic distributed object architecture to object interface definition language to object persistence. Despite the range of interests and loyalties, members believe that these are important issues. If the industry cannot collectively set its own standards, then it will be forced to deal with de facto standards set and controlled by a single, autocratic corporation.

We are all aware of the importance of standards to our customers. With standards, customers become less dependent on a single major supplier. With standards, customers are willing to take chances on smaller, start-up companies. With standards, customers are willing to try newer technologies.

For the industry of distributed objects, standards are more important than for any other industry. By its very nature, this is an industry that depends on interoperability. People must know how to describe, implement, and use objects that are distributed over unknown networks. People must be able to develop applications that work with different underlying frameworks. Objects from one company must be able to communicate and cooperate with objects from other companies. Whole systems must be able to make assumptions about basic object service infrastructures, just as today, programs can be written that are, to a large extent, ignorant of the underlying operating system.

For all its imperfections, the OMG is clearly the industry's best hope of achieving standards for object-based components. It has already achieved remarkable agreements in the following areas:

How object interfaces are defined. The OMG has defined IDL (Interface Definition Language), which gives a language-independent way of describing the public interface objects present to the world.

How operations are called on objects. The OMG has already defined language bindings for C and C++ and is working on other important languages.

How objects are distributed. The OMG has defined the basic features of the underlying architecture for support of distribution of objects across processes or machines. This architecture is called the CORBA (Common Object Request Broker Architecture). CORBA defines the ORB (Object Request Broker), which is the basic technology for distributing objects and routing method invocations. The OMG is now working on interoperability between ORBs, so that different implementations of the ORB can work cooperatively.

What types of object services are used. The OMG has voted on standards for many object services, including Life Cycle (how objects are created and destroyed), Naming (how objects are located by name in a multiuser context), Events (how objects create and respond to external events), and, of course, Persistence (how objects are stored on a long-term basis). It is the last of these services that is the focus of this book.
Outline of This Book

0. Introduction
This chapter provides an introduction to this book, a background to the OMG, a historical perspective on the problems of the object components industry, and biographical information about the author.

1. The Making of a Standard
Chapter 1 describes some of the political intrigue that went into this standard. This chapter will be of interest to people who like knowing about the politics of standards and who like to know the personalities involved in this kind of decision-making process. This chapter can be skipped by those who just want to understand the standard itself. For those of us who lived through the making of the Persistence Standard, this chapter is probably the most interesting in the book, and possibly the most controversial.

2. The Goals of Persistence
Chapter 2 describes the goals of the Persistent Object Service specification. It describes the concept of datastore independence, giving code examples. It also discusses the idea of datastore plugability, or how datastore vendors plug their products into this service. This chapter presents a high-level view of the POS architecture, especially as it relates to the client API (Application Programming Interface) and the datastore pluggable interface, the SPI (Service Provider Interface).

3. The OMG Object Model
Chapter 3 describes the OMG Object Model. It contains sections on location independence, implementation independence, and the Object Request Broker (ORB). It also describes the concepts of IDL, the OMG Interface Definition Language, which is described more fully in Chapter 4. Chapter 3 defines the basic concepts of interface, operations, and method implementations. It describes some of the major object services related to Persistence with sections on Life Cycle, Naming, Transactions, Concurrency, Security, and Query.

4. Introduction to IDL
Chapter 4 is an introduction to IDL. It describes the major components of an IDL definition, including method prototypes, most supported data types, environment, operations, attributes, and exceptions. It also describes the C bindings, which show how methods are implemented in C. Examples are given in the SOM implementation of the CORBA specification.

5. The Interfaces of Persistence
Chapter 5 describes each of the interfaces of Persistence, with detailed discussions on each of the operations. This chapter also points out problem areas in the specification and possible solutions.

6. The Application Developer Perspective
There are three major perspectives from which Persistence can be viewed. The highest view is as seen by the application developer, the person using object components to develop an application. Chapter 6 describes what application developers need to understand. It describes how Persistence can be related to Transactions, how embedded objects are managed, how persistent IDs are used, and how persistent IDs relate to object references.

7. The Object Implementor Perspective
Chapter 7 describes Persistence as seen by the object implementor, the person who is implementing object components that will serve as the building blocks for applications. Chapter 7 discusses the concept of protocol, that is, how data is moved in and out of an object. It describes the protocol based on the Externalization Service and gives the arguments for making this the universal protocol for all objects.

8. The Datastore Vendor Perspective
Chapter 8 describes Persistence as seen by a datastore provider wanting to plug into the service. This chapter describes exactly what such a datastore must implement in order to be an OMG compatible datastore. The chapter looks at some case studies of existing datastore products that are plugging into this service, including relational databases and POSIX files.

9. The Vision
Chapter 9 puts the Persistent Object Service in an overall context of software development, present and future.

One might ask why this book is necessary. After all, the OMG has published this standard, and it is freely available. Many products will soon be hitting the market, all claiming to be compliant with the OMG Persistence Proposal.

The official Persistent Object Service specification is sparse. It includes less than fifty pages and a large number of superfluous interfaces, interfaces that are included as examples on how something might be done, not requirements for how things must be done. Some of these examples were added not to elucidate, not to placate, as is often the case with a document that is as much a historical record of political compromise as it is an attempt to define a standard.

I have spoken to dozens of software developers who have tried to make sense out of the Persistence Specification and failed. These are highly intelligent engineers with many years of experience reading and interpreting technical documents. If engineers like these cannot make sense out of the specification, what hope has the application developer?

Yet it is my belief that the ideas of the Persistence Specification are simple. When I have explained the standard, I have had few problems. It is the specification that is obviously complicated, not the ideas behind it.

I believe this book will fulfill a critical need. I hope it will accomplish the following purposes:

Give enough background about the overall OMG architecture and object programming model so that readers can understand how Persistence fits into the overall picture.

Describe the architectural goals the POS was intended to accomplish.

Describe the client programming model, showing exactly how client code stores and restores objects.

Describe how objects should be written so that they can be stored in any OMG compliant datastore.

Describe how datastore products plug into the service, with examples of existing datastore products that have already been integrated into this service.

Describe some of the problems with the standard and show how these might be resolved in the future.

If you are either a client of persistence, a producer of persistence products, or just one who is interested in a major standard, one that will have a dramatic influence on object persistence products and the industry as a whole over the next ten years, this book is for you. If you work for a company that is using, or expects to be using object technology over the next few years, you cannot possibly afford to be unaware of this work.

If you are considering buying an object-oriented database in the near future, you need to understand this important alternative.

Acknowledgments

I am always nurtured by the constant faith and encouragement of my wife, Alice Sessions. She is a natural-born teacher and realizes the value of a good book, especially a good book that has actually been finished.

Like all great teachers, she knows when to prod, when to encourage, and when to lie low.

My children, Emily and Michael, are both intrigued by the book-writing process. They have learned to put up with the eccentricities of a father who carries a computer more often than a wallet and who will whip out his laptop at a birthday party (never my own children's, I do have some sense of priorities!), at a skating rink, or at a fast food stop, and just "jot down a few notes."

Many people have been part of the Persistence Specification, and I owe all of them a debt of thanks. The most important is Dan Chang, of IBM Santa Theresa. Dan worked closely with me for over a year, developing the ideas that became the OMG specification and convincing the world that these ideas were important. In The Wisdom of Teams, Katzenbach and Smith describe these characteristics of high performance teams:

They are obsessive about their goals.

They are composed of team members who are exceptionally committed to each other.

They outperform all reasonable expectations.

Dan and I were such a team, and it was one of the great experiences of my professional career.

Others contributed to the OMG Persistence Specification. George Copeland, of IBM Austin and Mike Powell, of SunSoft edited the final compromise and added several good technical ideas. Rick Cattell, of SunSoft was involved in some of the early discussions. Don Belisle, of IBM Austin, coauthored my original OMG Persistence proposal. Alan Synder and Mark Hepner, both from SunSoft, were part of the original IBM/SunSoft team trying to work out a common architecture. We received good review comments from Steve Munroe, Mike Conner, and Ashok Malhatra (all IBMers), among others. We received management support from Jerry Ronga, Jo Cheng, Larry Loucks, and Don Haderle. Guylaine Cantin worked closely on the first implementation of the Persistence Specification and contributed many original ideas on plugging relational databases into the persistence framework. Bob Orfali, coauthor of The Client/Server Survival Guide and many other books on my essential reading list, has been a great supporter and special advisor over the years.

I like to write in coffeehouses. Fortunately, Austin has a wonderful collection of coffeehouses that will let you unfold your laptop, spread out your papers, and lose yourself in the process of writing, all for the cost of a cup of coffee. The one where I have written more of this book than any other is "Texpresso." I appreciate Dave and Scott's good-natured tolerance of my activities and their constant refueling of my creativity with the best cappuccino in Texas.

This book has benefited from many careful reviewers. I especially thank Guylaine Cantin, who gave an extraordinary line-by-line review. Also, George Copeland, Mark Hapner, John Henekel, Bob Orfali, Charlie Redlin, and Clovis Tondo have all given a thorough reading and have contributed many excellent suggestions.

Prentice-Hall is, as always, a pleasure to work with. I am very grateful to my ever supportive editor, Greg Doench, and for the careful work of my copy editor, Mary Lou Nohr, who also created the index.

Although this book discusses the work of many people and work done during my tenure at IBM, nothing in this book should be taken as representing the opinion of anybody other than myself, and nothing in this book should be taken as a commitment by IBM to produce any particular product or to add any particular features to any product.

About the Author
Roger Sessions was one of the principal architects of the OMG Persistent Object Service Specification and was the technical lead for the first IBM Persistent Object Service Implementation. He was the Architect and Lead Programmer for the Persistence Framework of SOM version 1.0, one of the IBM products on which the POS specification is based. He was on the IBM SOM programming team since its inception in 1990 until 1995, when Roger left IBM to found ObjectWatch, Inc., a company specializing in offering training, consulting, and mentoring to companies starting to adopt Distributed Object Technology. He now travels throughout the world teaching and consulting.

Roger is the author of two other books: Class Construction in C and C++; Object-Oriented Programming Fundamentals and Reusable Data Structures for C. He is the coauthor of many papers on the System Object Model (SOM), IBM's implementation of the OMG CORBA specification. He has spoken at over thirty conferences throughout the world on the principles of object-oriented programming, C++, SOM, and object persistence. He has given SOM tutorials at OOPSLA, OS/2 World, IBM OO conferences, and others, and has consulted on many large-scale SOM projects. He is widely considered the world's leading expert in SOM and DSOM technology.
He can be reached through ObjectWatch, Inc., in Austin Texas.ros

Read More