Object Persistence: Beyond Object Oriented Databases

Sessions, Roger

ISBN 10: 0131924362 ISBN 13: 9780131924369

Publisher: Prentice Hall, 1996

Synopsis

A programmer's guide to the IBM Object Management Group's new CORBA standard for the Persistence Object Service (POS) and the implementation in SOMobject 3.0. Sessions, one of the chief architects and developers of the IBM object database implementations, describes the OMG object model and services related to Persistence, interfaces, and various application models, including how different datastores can be plugged into the Persistence Framework. Lacks a bibliography. Includes examples. Annotation c. by Book News, Inc., Portland, Or.

About this title

From the Publisher:

This book describes the Object Management Groups standard for the Persistence Object Service (POS), and the client programming model, showing exactly how client code should be written to store and restore objects. The next generation of Object Persistence products will be based on this important specification.

From the Inside Flap:

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™, Stream files, and other datastores. This book describes the interfaces used for storing and 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 protoco...

About this edition

• Publisher: Prentice Hall
• Publication date: 1996
• ISBN 10: 0131924362
• ISBN 13: 9780131924369
• Binding: Textbook Binding
• Edition number: 1
• Number of pages: 272