Framework for Object-Oriented Interface to Record File Data

1. Field of the Invention

The present invention relates generally to manipulation of stored data and, more particularly, to manipulating data in record file data storage systems through object-oriented programming techniques.

2. Description of the Related Art

The dominant method of representing and storing data in computer databases follows a top-down, procedural data model. In the procedural model, systems are represented as a collection of states whose condition at any particular time are represented by data values stored in record-oriented data files. The data values are changed through the operation of an application program. Generally, a user accesses an application program and manipulates the data representing a system through an application program interface (API). The functions performed on the data values by the application program and the record file data structures are matched to a particular data model problem-solution format and are not easily re-used for other application programs.

Record file data generally comprises three types of data file representations: sequential files, relative files (also called direct files), and keyed files. A typical record-oriented file management system will support each of these record file types. Examples of record-oriented file systems are "SFS" by TransX Corporation, "VSAM" by International Business Machines Corporation (IBM Corporation), "Btreive", and "LANDP". Accessing such record-oriented data files typically requires applications programs written in what are generally referred to as procedural computer languages, such as FORTRAN, COBOL, Pascal, C, or assembly language.

Data stored as a sequential file consists of data records (strings of data words) that are recorded sequentially, such as in a magnetic tape drive data storage system. Thus, both data storage and data retrieval must be performed sequentially. Data stored as a relative file consists of data records that are numbered and indexed. Therefore, data in a relative file can be independently accessed; relative files permit random access to particular files. Finally, keyed files are files in which each data record can have one or more key fields. Data records are accessed according to the value of the one or more data keys. Thus, specifying a key value specifies a corresponding data record.

Many newer application programs and API's are being developed according to the object-oriented programming (OOP) data model. The OOP data model views complex systems as a collection of interrelated, cooperative objects that are instances of classes that typically include corresponding methods (also called operations or functions). Thus, an object is said to encapsulate class attributes (or data structures) and methods. The number of objects that might exist in a given OOP model is limited only by the size of computer memory.

Another OOP notion is that of inheritance, which refers to the ability of object members in one class, called a subclass, to incorporate the attributes and functions of members in another class, called a superclass. In this way, object procedures specified by a class definition can be reused again and again by object instances of the class at the time the program executes.

An inherited method in a subclass object generally can be changed in one of two ways. First, a method override can occur when the program code for functioning of a method is replaced by alternative code from the subclass. A second way of changing a method occurs with a method extension, when the program code from the superclass is retained, but program code from the subclass is added to perform additional functions. Other OOP advantages are simpler program coding, easier program maintenance, reduced complexity of the system model, increased program reuse, and the ability to specify a framework of reusable definitions for classes of objects.

The concept of a framework is a vital part of the OOP data model that provides the advantages desired by OO programmers: a framework is a specification of the classes and the relationships between classes of an OOP data model. That is, a framework comprises a class hierarchy that can be used over and over again, with overrides and extensions. In this way, an initial problem solution specified by a class hierarchy can be adapted and customized for new circumstances, simplifying program maintenance. Common OOP languages in which object applications are written include Simula, Smalltalk, and C++.

Communication between OOP applications developed by different programmers is being facilitated by the work of the Object Management Group (OMG), an industry consortium. One standard of program-to-program communication, for example, is specified by the Common Object Request Broker (CORBA) standard promulgated by OMG.

It should be understood that data created by and for object-oriented programs is stored differently from data created by and for record-oriented data files. Data stored for object-oriented programs do not necessarily correspond to the record format types of sequential, relative, and keyed, due to the different nature of the system model and the manner in which data is stored. Thus, record file database systems such as "SFS", "VSAM", "Btreive", and "LANDP" referred to above are not generally compatible with object-oriented programming data.

The concepts of OOP do not easily lend themselves to interface with conventional record file database programming using the procedural model. As noted above, a hallmark of the procedural model is the representation of a system as a collection of data values that are maintained in a datastore, such as magnetic disk storage or memory. This quality of static data storage is referred to data persistence.

In the OOP data model, the attributes of an object are allocated memory space only for so long as the corresponding object is needed. When the object is no longer needed, it is deleted from memory. In this way, object methods are implemented at the time of execution by message passing from object to object at run time. This is generally referred to as dynamic binding. Object methods are therefore said to be polymorphic, because they can assume different implementations at different points in an executing program. Thus, OOP data is not generally persistent because it does not exist after a programming session of an OOP application ends.

Object data that is to persist from session to session can be stored directly as objects in an OOP database or can be converted to record data storage. An object that is stored as record data must be retrieved and then converted back into object representation before being used in an OOP application. In an OOP database, the condition of objects is stored, comprising the value of the object attributes and the operation of the methods. An object retrieved from an OOP database can immediately be used in an executing OOP application.

Users of OOP application programs want to be able to access record-oriented data. Users of such programs do not want to be bothered with the OO-to-record interface problem. As a result, API developers, who create application programs, want to utilize programming interfaces that make the OO-to-record data interface as transparent as possible for their own development efforts and certainly for end users of their application programs.

The data access interface to persistent data from the perspective of API programmers is generally classified at one of four levels. Level 1 access is provided where persistent data is stored and retrieved from OOP applications directly as objects. Level 2 access is provided where persistent data is stored as record data and the record-oriented nature of data is apparent to an API programmer, in that record store and retrieve operations are used to access data maintained on the datastore. Level 2 access would be provided, for example, by a data access product that complies with the Persistent Object Service (POS) standard specified by the OMG. Level 3 access is provided where procedural programming, record data commands are translated to corresponding object-oriented commands, thereby comprising what is called an OO "wrapper". For example, the IBM Corporation "Common Object Datastore Adapter" (CODA) project translates record-oriented "x/open" commands to corresponding OO commands and thereby provides Level 3 access. Finally, Level 4 access is generally provided where a data access product relies on OO language libraries for data access such that the record data nature of underlying data is readily apparent to the API programmer.

A variety of OOP data file management systems have been developed. One system, for example, is based on a generalized object data model from IBM Corporation called the "Standard Object Model" (SOM) and the corresponding data access file management system is called "Persistent Object Service for SOM" (POSSOM). The POSSOM system makes use of an IBM Corporation data class hierarchy (a framework) called the "Persistent Object Framework" (POF). The POSSOM system provides an interface that can be used by API program developers to create object-oriented applications that utilize store and retrieve operations to access persistent object data maintained on disk storage. The POSSOM system thus provides Level 2 access.

The framework on which POSSOM is based defines two interfaces. The first interface is a client code interface that describes how clients request persistent operations on objects regardless of underlying datastore. The client code interface is implemented through a "Persistent Object Manager" (POM) that permits persistent objects to implement persistence independently of the datastore. The second interface is a datastore interface that describes how a datastore provider "plugs" a new datastore into the POSSOM system. The datastore interface is commonly referred to as the "Abstract Persistent Data Service" (PDS). In particular, the POSSOM system provides a PDS interface to byte stream files of the type specified by the operating system standard known as Portable Operating System Interface (POSIX).

In accordance with the generally accepted OOP model, any datastore object that can be implemented as a specialization of the PDS is assured of being compatible with the POSSOM system. Such datastores can be used as repositories for any object that implements persistence through the POM interface, regardless of whether that object makes its persistence visible through the Persistent Object interface. That is, PDS-compatible datastores can be used as repositories for any object that implements persistence through the POM interface, regardless of whether that object implements persistence through the POM interface. The Level 2 access through the Persistent Data Service (PDS) of POSSOM permits storage and retrieval of data from objects by establishing a protocol. PDS preferably recognizes multiple types of protocols, including a "byte stream" protocol.

The "Common Object Datastore Adapter" (CODA) from IBM Corporation is tailored for use with record data file systems such as the "DB2" and "IMS" systems from IBM Corporation to provide Level 3 access. The CODA system provides an API programmer with access to record-oriented data using such DB2 commands as "fetch" and "carry". The CODA system provides an object-oriented API to databases such as created using the "DB2" and "IMS" products of IBM Corporation. The CODA system provides the access by using a "Dynamic Data Object" (DDO) to contact a "Data Store Manager" (DSM) module. One desirable feature of the CODA system is that it is protocol independent. Another interface that provides access of the Level 3 type is the "Taligent Data Access Framework" from Taligent Corporation.

Development of application programs that can interface record-oriented data files to multiple object-oriented access levels is complicated by the generally incompatible Level 2 and Level 3 interfaces. That is, an application programmer who wants to develop an application that can access data through both POSSOM and CODA might be required to write two different applications because POSSOM and CODA utilize different protocol schemes and class hierarchies to define their respective object classes and methods. Alternatively, an API programmer would be required to provide two API environments to accommodate the different access levels of service. In both cases, multiple programs also might be needed to deal with the different types of record storage. Such duplicative efforts are wasteful of programming resources and result in extra costs.

From the discussion above, it should be apparent that there is a need for a system that permits data access between multiple record-oriented data file systems and multiple object-oriented file management systems across different protocol types. The present invention satisfies this need.

In accordance with the invention, a two-way object-oriented framework provides an interface that can be plugged into multiple OOP-to-record file data management systems to provide multiple types of object-oriented application programs with access to record-oriented data files, and can receive multiple record file adapters to provide OOP applications with access to multiple types of record-oriented data files. The present invention thereby provides a method and apparatus that permits API programmers to easily create OOP applications that manipulate data in record file data storage. In particular, the invention provides an object framework used by a persistent object data manager to access data stored in a record file data structure. In this way, the present invention provides a uniform interface to permit OOP applications with the ability to store, retrieve, and delete data stored in record file data storage. By defining specialized objects, the framework can interface with a variety of OOP data managers and formats, such as those called POSSOM and CODA, and also can interface to a variety of record file data systems, such as those called SFS, VSAM, DB/2, LANDP, and Btreive. In this way, the present invention provides a system that permits data access between multiple record-oriented data file systems and multiple object-oriented file management systems across different protocol types, thereby assisting API program developers with the creation and maintenance of object-oriented application programs that can interface with record-oriented datastores.

In one aspect of the invention, the framework includes five object classes that provide: (1) a persistent identifier of the access path for persistent object data storage, including specification of a datastore name, data identifier, and schema mapper; (2) a persistent data service object abstraction that will interface with an existing persistent data service and that will support multiple data protocols; (3) a datastore manager that manages the record file datastores; (4) a schema mapper that permits an API programmer to specify the mapping between object data and the record file data; and (5) a record file adapter that provides a mapping between the datastore manager and the various procedural, record-oriented file systems.

Using the five object classes described above, a framework constructed in accordance with the present invention can instantiate various objects to permit specialization of features. In this way, a system that implements a framework in accordance with the invention can support an OOP interface to streammable data objects and can map object data to VSAM/X record-oriented file systems.

In another aspect of the invention, a framework implemented in accordance with the present invention permits both Level 2 and Level 3 access to record-oriented data file systems through POSSOM and CODA systems, respectively.

Other features and advantages of the present invention should be apparent from the following description of the preferred embodiment, which illustrates, by way of example, the principles of the invention.

FIG. 1 is a functional block diagram of a computer system constructed in accordance with the present invention.

FIG. 2 is a functional block diagram of the POS.sub.-- RF framework components showing how the two-way interface of the framework to both the Persistent Object Framework (POF) and record file data adapters.

FIG. 3 is a functional block diagram of the POS.sub.-- RF framework components showing how the components interface with existing persistent data service systems, such as POSSOM and CODA.

FIG. 4 is a representation of the mapping that occurs between a protocol defined by the schema mapping and the record data files.

FIG. 5 is a flow diagram that illustrates the processing steps performed by the framework of the computer processing system illustrated in FIG. 1.

FIG. 6 is a top-level category diagram representation of the POS.sub.-- RF framework of the computer processing system illustrated in FIG. 1.

FIG. 7 is a class diagram representation of the POS.sub.-- RF system showing the classes implemented by the computer processing system illustrated in FIG. 1.

FIG. 8 is a class diagram representation of the PDS.sub.-- RF category implemented by the computer processing system illustrated in FIG. 1, showing the method names.

FIG. 9 is a class diagram representation of the DSM.sub.-- RF category implemented by the computer processing system illustrated in FIG. 1, showing the method names.

FIG. 10 is a class diagram representation of the SM.sub.-- RF category implemented by the computer processing system illustrated in FIG. 1, showing the method names.

FIG. 11 is a class diagram representation of the PID.sub.-- RF category implemented by the computer processing system illustrated in FIG. 1, showing the method names.

FIG. 12 is a class diagram representation of the RF.sub.-- ADP category implemented by the computer processing system illustrated in FIG. 1, showing the method names.

The preferred embodiment of the present invention comprises a framework that, when implemented in an object-oriented programming environment, provides a data access service for persistent object data associated with record file datastores. For ease of reference, the framework will be referred to by the name "POS.sub.-- RF". The POS.sub.-- RF framework is designed to interface with multiple object data services to provide multiple-level data access. In this way, the POS.sub.-- RF framework provides a mapping between persistent object data and record file data. In addition, the framework has the flexibility to support multiple data protocols. The POS.sub.-- RF framework can be used by a developer of an API that will comprise an object-oriented application program that must interface with record file data. In this way, the object-to-record interface will be completely transparent to users of the application program, who will be able to access record file data from the object-oriented user interface.

The POS.sub.-- RF framework consists of five object classes, described further below, that provide essential functions including persistent object identification, persistent data service in connection with Level 2 access, datastore management in connection with Level 3 access, schema mapping, and record file adapters that provide a mapping from a datastore management object and the record file systems with which data transfer will be accomplished. With objects comprising appropriate class extensions that depend on the precise programming environment confronted by the framework developer, the POS.sub.-- RF framework provides a two-way object-oriented framework that can be plugged into multiple OOP-to-record file data management systems to provide object-oriented application programs with Level 2 and Level 3 access to record-oriented data files, and that can receive multiple record file adapters to provide OOP applications with access to multiple types of record-oriented data files. Thus, the invention provides a single interface that accommodates multiple OOP platforms and thereby permits API programmers to easily create OOP applications that manipulate data in record file data storage.

The POS.sub.-- RF framework is implemented and executed on a computer system that supports an object-oriented programming environment such as exemplified by programs written in the C++ language. In the preferred embodiment, the POS.sub.-- RF framework receives client commands from a Level 2 access system such as POSSOM to manipulate record file data and also receives data manipulation commands from a Level 3 access system such as CODA. The POS.sub.-- RF framework provides the persistent object service (POS) defined by the Object Management Group (OMG) standard, thereby providing a uniform interface to store, restore, and delete persistent object data in and from record file datastores. Thus, the POS.sub.-- RF framework solves the problem of mapping between client object data and system record file data. The POS.sub.-- RF framework is compatible with the Persistent Object Framework (POF), so that it can interface with Level 2 and Level 3 access systems, and also can receive multiple record file system adapters to provide an interface to corresponding record file datastore systems.

FIG. 1 is a block diagram of a computer system 100 constructed in accordance with the present invention. The computer system illustrated in FIG. 1 supports an object-oriented programming environment suitable for the POS.sub.-- RF framework and includes a client station 102 that communicates with system storage datastore 104 over a network 106. The system storage datastore 104 can comprise, for example, a direct access storage device (DASD) such as magnetic disk drive, magneto-optical storage, or magnetic tape storage, or can comprise a collection of linked DASD units comprising a magnetic disk drive storage array or the like.

A user at the client station 102 carries out data operations that generate or utilize object data and can specify data access operations (such as store, retrieve, delete) on record file data contained in the system storage datastore 104. Alternatively, the datastore operations can be performed on record file data contained at the client station 102 in storage described further below. The client station 102 also can be used to specify the appropriate extensions to the POS.sub.-- RF framework to thereby generate appropriate instances of objects to provide the desired interface.

The client station 102 includes a central processing unit (CPU) 108, a display 110, and a main memory 112. Processing operations are executed under control of the CPU, which communicates with the network 106 and other client station components over a system bus 113. The CPU operates in response to user commands, which it receives via a keyboard 114 or a graphical interface input device 116, such as a display mouse, joystick, or track ball. As noted above, the POS.sub.-- RF framework permits the API programmer, who generates applications that manipulate data, to provide a transparent OO-record data interface to application users. Accordingly, a user at the client station 102 can be either a POS.sub.-- RF framework user or an application program user. The client station 102 can communicate with one or more other client stations or network server units 115 over the network 106. It should be understood that the other network stations or servers 115 have a construction similar to the client station 102. Those skilled in the art will appreciate that a server 115 typically controls access to system datastore, such as the system storage 104 depicted in FIG. 1.

The client station 102 also includes a DASD interface 118 that can receive and read computer program products 120 comprising machine-readable storage devices such as, for example, integrated circuit chips or magnetic media disks or tapes, on which are recorded program instructions or data. The machine-readable storage devices also can comprise, for example, media such as optical disks. The client station 102 also communicates with other stations, servers, or mainframe computers over the network 106. This permits the client station 102 to receive data into the main memory 112 over the network 106 after network communication has been established using well-known methods that will be understood by those skilled in the art without further explanation.

When properly extended by an API developer, the POS.sub.-- RF framework provides an object-oriented interface between the client station 102 and data contained in the system datastore 104. The extended POS.sub.-- RF framework can be maintained at a network server 115 or can be maintained at the client station 102. Copies of the extended POS.sub.-- RF framework can be provided to users from a server 115 by means of network access methods or can be provided by copying onto instruction-bearing media computer program products, such as floppy disks 120.

The main memory 112 contains a variety of data structures and information, including an operating system 124, data 126, objects 128, and application programs 130. The main memory is represented as a single entity, but those skilled in the art will appreciate that the main memory can comprise a combination of random access memory (RAM), hard disk drives, optical disk drives, and other storage devices containing logically segmented storage locations. One of the application programs in the main memory 112 of the client station 102 is a POS.sub.-- RF application program containing a sequence of program instructions whose execution implements the present invention.

The operating system contained in the main memory 112 supports an object-oriented programming environment for the execution of object-oriented programs, such as those written in, for example, the C++ programming language. Accordingly, the memory contains program objects that are data structures of an object-oriented programming language. Application programs are invoked, or launched, by a user interface action through the keyboard 114 or graphical input device 116. The application programs can be written in a variety of languages, including C++.

The CPU 108 can comprise any one of many platforms, including the International Business Machines Corporation (IBM Corporation) Model PS/2.RTM. personal computer, IBM Corporation Model RS/6000 workstation, and the like. In the preferred embodiment, the graphical input device 116 comprises a display mouse, but it can be substituted with other devices that provide the same function and control, such as a track ball or joystick, which are well-known to those skilled in the art and require no further explanation. Thus, references to the display mouse will be understood to include alternative devices such as track ball and joystick controllers. Likewise, references to mouse buttons and other mouse features will be understood to include equivalent mechanisms for track balls, joystick devices, and the like.

The display 110 comprises a display device such as a video terminal that displays computer output and indicates system operations. Display objects can be pictured on the display and the user can designate data operations on the display by using the graphical user input device 116.

FIG. 2 shows how the POS.sub.-- RF framework communicates with both the Persistent Object Framework (POF) of client application programs and record file data contained in system datastores. FIG. 2 is a block diagram representation of the object classes of the POS.sub.-- RF framework that illustrates the flow of control and communications between the five object classes of POS.sub.-- RF mentioned above.

FIG. 2 shows that client code, comprising an object-oriented application program that is used to manipulate record file data, interfaces with programming that is structured in accordance with the Persistent Object Framework (POF), which in turn interfaces with an Abstract Persistent Object Data Service (PDS) that ordinarily provides a data interface of either a Level 2 or Level 3 access type. The POS.sub.-- RF programming interface to the client code presents itself at the PDS with a block labelled PID.sub.-- RF, which represents an operating component of the POS.sub.-- RF extended framework that is specialized to interface to record file datastores.

Within POS.sub.-- RF, the PID.sub.-- RF component interfaces with a component block shown in FIG. 2 labelled Persistent Data Service for Record Files (PDS.sub.-- RF), which in turn interfaces with a component called Datastore Manager for RF (DSM.sub.-- RF). The DSM.sub.-- RF must interface with another component, SM.sub.-- RF, that specifies schema mapping between object data and record data via appropriate record file adapters. The Abstract Record File Adapter (RF.sub.-- ADP) is an abstract class "wrapper" that provides a mapping between the DSM.sub.-- RF and various procedural record-oriented data file systems. Finally, FIG. 2 shows RF.sub.-- ADP communicating with multiple record file adapters to provide adapters specialized for particular record file systems. The multiple record file adapters of FIG. 2 are generically labelled RF.sub.-- 1.sub.-- ADP, RF.sub.-- 2.sub.-- ADP, RF.sub.-- 3.sub.-- ADP, . . . , RF.sub.-- X.sub.-- ADP.

As noted above, the POS.sub.-- RF framework implements the Persistent Object Service (POS) specified by the OMG standard, and is designed to interface with multiple data access services to provide multiple-level data access. For example, in the preferred embodiment the extended POS.sub.-- RF framework interfaces with (can be plugged into) the Level 2 data access service called Persistent Object Service for the System Object Model (POSSOM) and also interfaces with the Level 3 data access service called Common Object Datastore Adapter (CODA). The POS.sub.-- RF framework is designed for implementation on multiple platforms using the SOM Interface Definition Language (IDL) and language binding with the C or C++ programming languages.

FIG. 3 is a functional block diagram of the POS.sub.-- RF framework components showing how the components interface with existing persistent data service systems, such as POSSOM and CODA. That is, FIG. 3 is a representation of the interface between POS.sub.-- RF and the POSSOM and CODA systems. Conventionally, data access services provide only Level 2 access (such as POSSOM) or provide only Level 3 access (such as CODA). Therefore, the present invention permits interfacing to both POSSOM and CODA projects without duplicate programming efforts.

FIG. 3 shows that the POSSOM object-oriented data service receives requests for record data access from a client interface (labelled "Client") at a module called Persistent Object (PO), which then communicates with a POSSOM module called Persistent Object Module (POM). The POM interfaces with a Persistent Data Service (PDS) module, which then actually communicates with a record file datastore. When the POS.sub.-- RF framework is plugged into POSSOM, the client interface with POS.sub.-- RF is through the PDS.sub.-- RF module. That is, POS.sub.-- RF receives a Level 2 request for record data at the PDS.sub.-- RF module. The request is processed and is passed on to the DSM.sub.-- RF module, from there to the SM.sub.-- RF module, and then through the RF.sub.-- ADP modules to the record datastore. FIG. 3 also shows that requests for "streammable" data can be received by the DSM.sub.-- RF directly from the POSSOM client.

FIG. 3 shows that the CODA object-oriented data service receives requests for record data access from a client interface (labelled "Client") at a module called Dynamic Data Object (DDO), which then communicates with a CODA module called Datastore Manager (DSM). The DSM of CODA interfaces with the POS.sub.-- RF DSM, which then communicates with the POS.sub.-- RF modules SM.sub.-- RF and RF.sub.-- ADP and then finally to the actual record file datastore. Thus, when POS.sub.-- RF is plugged into CODA, the client interface with POS.sub.-- RF is through the DSM.sub.-- RF module. That is, POS.sub.-- RF receives a Level 3 request for record data at the DSM.sub.-- RF module.

The POS.sub.-- RF framework supports multiple OO access levels primarily through the DSM.sub.-- RF component, which functions as a datastore manager for record files. In the preferred embodiment, for example, a client (user application) achieves Level 2 access by using the POS standard operations that are associated with the client persistent object data, as defined by the POS standard of the OMG, to access record data. The Level 2 interface between the POS.sub.-- RF framework and the data interface specification (the interface specified by the POF standard) is through the PDS.sub.-- RF. The PDS.sub.-- RF interacts with the DSM.sub.-- RF to access the record data files. A client achieves Level 3 access by using an OO wrapper on top of an "X/Open" CLI equivalent operation of CODA. That is, the interface between POS.sub.-- RF and CODA is through the DSM.sub.-- RF, which comprises the wrapper on top of the RF.sub.-- ADP. The DSM.sub.-- RF is specialized to support particular DDO protocol types.

The POS.sub.-- RF framework maps object data and records by defining the access path to record-oriented data maintained in the datastore, and translates the data format between the object data programs and the record data. The POS.sub.-- RF framework uses the persistent identification PID.sub.-- RF object class illustrated in FIG. 3 to define the access path of the persistent data and uses the SM.sub.-- RF object class to do the mapping between the object data and the record file data.

POS.sub.-- RF defines the access path of persistent OO data using the PID.sub.-- RF object, based on the assumption that each persistent object has a unique path identification (pathname) and the assumption that each persistent object is mapped to a single data record. In particular, the PID.sub.-- RF is a subclass of PID.sub.-- DS, an object class of a persistent data service such as POF. For example, instructions to implement the PID.sub.-- RF definition (without implementation details) might be represented by the pseudocode of Table 1 below:

The file is identified by the datastoreName (file name) or by the connect.sub.-- id. If the datastoreName is not set in the PID.sub.-- RF module, then it is assumed by POS.sub.-- RF that the file is open and connect.sub.-- id is the file handle. Otherwise, the file will be opened and the connect.sub.-- id will be set by the PDS.sub.-- RF module. The client can get the connect.sub.-- id as an attribute of PID.sub.-- RF and use it for other objects in the same file. Those skilled in the art will appreciate that the connect.sub.-- id is available to the client for the purpose of reducing application programming efforts and the overhead associated with file open and close operations.

In the Table 1 pseudocode, the attribute dataNew gives the option of creating a new datastore. If the value of datastoreNew is set to "true", then POS.sub.-- RF will expect that the information for file creation is given in the schema mapper. The name "sm.sub.-- mapper" identifies the specialized SM.sub.-- RF module for the application. The "data.sub.-- id" entry in Table 1 identifies the position of a record in a file. The data.sub.-- id is a union data structure formed by combining a record number or key defined by the data.sub.-- id type. The data.sub.-- id also has flags that allow optional information to be associated with the PID.sub.-- RF module.

The schema mapper SM.sub.-- RF module provides a mapping between the object data protocol and the record datastores and also creates a new record file datastore by specifying a record and a key format. Thus, the mapping is dependent on a protocol, while the new record creation is protocol independent. The interface definition of the SM.sub.-- RF module, Instructions to implement the SM.sub.-- RF interface definition (without implementation details) might be represented by the pseudocode of Table 2 below:

In Table 2, the proto2rec() and the rec2proto() methods are defined to transfer data between the protocol and the record datastore, as shown in FIG. 3. The operation of POS.sub.-- RF assumes that the underlying record file system does not have the record field support. Such record file systems include VSAM/MVS, VSAM/X, VSAM/2, and CICS FC, provided by IBM Corporation. Thus, how actual data is arranged in a record is based on what is known by an application. The two operations need to be overridden by the application during extension of the framework. The POS.sub.-- RF system provides sample code to guide the application in overriding.

FIG. 4 is a representation of the mapping that occurs between a protocol defined by the SM.sub.-- RF schema mapping module and the record data files. An object attribute dsSpec and an operation create.sub.-- ds() are used to specify the file type, record data format, and other information needed for file creation. The SM.sub.-- RF module is used by the DSM.sub.-- RF module to implement persistent operations. When the SM.sub.-- RF is specialized, or extended, by an application, the name of the dsSpec object is an attribute of the PID.sub.-- RF module. The DSM.sub.-- RF can instantiate the schema mapper SM.sub.-- RF by getting the module name from the PID.sub.-- RF, then transfer the data between the protocol and the record data. Thus, getting and putting data from and into the object is achieved through the protocol supported by the persistent object.

The difference between the SM.sub.-- RF object and the schema mapper in the PDS used by the DB/2 system for direct access is the separation of data mapping from data accessing. That is, the DB/2 schema mapper handles both the data mapping and the SQL accessing. The SM.sub.-- RF of the POS.sub.-- RF system handles the data format mapping, but not the data accessing. In this way, schema mapping concerns are isolated from PDS data accessing concerns, thereby permitting reuse of the data accessing code for general purposes.

One advantage of object-oriented programming over procedural programming is the encapsulation of code (programming instructions) and data. The subtyping technique used in the POS.sub.-- RF framework permits reduced development time and effort for protocol issues. By subtyping PDS.sub.-- RF, DSM.sub.-- RF, and SM.sub.-- RF, specialized subclasses for a specific protocol can be derived. These protocol subclasses can be characterized, for example, as PDS.sub.-- xxx.sub.-- RF, DSM.sub.-- xxx.sub.-- RF, and SM.sub.-- xxx.sub.-- RF, where the "xxx" is the name of the protocol. With such specializations, only the operations dealing with data transfer need to be overridden. The protocol independent portion of DSM.sub.-- RF and SM.sub.-- RF, such as operations related to files, can be reused. These operations would include open, close, and create operations.

FIG. 3 shows how POS.sub.-- RF is constructed to handle different protocols, where "STRM" represents the IBM Corporation "Streammable" protocol and "DDO" represents the DDO protocol discussed above. Thus, the POS.sub.-- RF framework encapsulates the implementation of the RF.sub.-- ADP and its specialization from the implementation of protocol dependent code. By defining the abstract RF.sub.-- ADP, the implementation of a specialized adapter, such as RF.sub.-- ADP.sub.-- VSAM for VSAM files, can be developed without being effected by the protocol. Because approximately three-fourths of the code is at the record data adapter level, the development effort to support any new protocol should be relatively little.

FIG. 5 is a flow diagram that illustrates the processing steps performed by the extended framework of the computer processing system illustrated in FIG. 1. Details of extending the framework to achieve the desired processing will depend on the programming environment within the computer system in which the framework extension will be executed, such as the system illustrated in FIG. 1. Such details will be understood by those skilled in the art, in view of the description and drawings herein, without further explanation. The processing steps illustrated in FIG. 5 represent programming instructions executed by the FIG. 1 computer system under control of the CPU 108, in accordance with well-known object oriented programming principles.

The first processing step illustrated in FIG. 5, indicated by the flow diagram box numbered 202, represents the generation of the necessary extended framework objects that comprise POS.sub.-- RF, including the above-described processing objects called PID.sub.-- RF, PDS.sub.-- RF, DSM.sub.-- RF, SM.sub.-- RF, and the family of RF.sub.-- ADP objects. The processing of this step 202 also includes generation of specializations for particular protocols and record data types. For example, it might be necessary to generate a group of PDS.sub.-- STRM.sub.-- RF and DSM.sub.-- STRM.sub.-- RF objects to handle streammable protocols, and it might be necessary to generate PDS.sub.-- DDO.sub.-- RF and DSM.sub.-- DDO.sub.-- RF objects to handle DDO protocol data records. Similarly, it might be necessary to generate a RF.sub.-- ADP.sub.-- VSAM record file adapter object to map DSM.sub.-- RF to the IBM Corporation VSAM/X record file system. Such object creation processing is included in the processing of the box numbered 202.

The processing illustrated by the flow diagram box numbered 204 represents receiving a request from a client process for a data access operation. The request might comprise, for example, a user at a user station 102 shown in FIG. 1 requesting storage or retrieval of a persistent data object defined by a user station object-oriented application. The next processing step, represented by the flow diagram box numbered 206, is to provide the request to the appropriate POS.sub.-- RF module for further processing. That is, using object oriented programming techniques, the computer system CPU ensures that the client data access request is received by the proper POS.sub.-- RF module. For example, Level 2 requests received from a POSSOM system are routed to the PDS.sub.-- RF module, while Level 3 requests received from a CODA system are routed directly to the DSM.sub.-- RF module.

The next processing step involves determining the access path of a persistent object of the client, using the PID.sub.-- RF object. This processing is represented by the flow diagram box numbered 208. Next, the processing represented by the flow diagram box numbered 210 indicates that a mapping of the persistent object to the record data stored in the system datastore is determined, using the SM.sub.-- RF schema mapping object. In this step, the storage location of the record file in the datastore is matched to the persistent object referenced by the client process. Finally, the last data access processing step is represented by the flow diagram box numbered 212, which indicates that the data access operation received from the client is executed. The data access operation can comprise any data operation permitted by the data service through which the user interfaces with POS.sub.-- RF, such as operations passed from the client to the persistent data service such as POSSOM or CODA. The processing of the data access operation is then complete.

FIG. 6 is a top-level category diagram representation of the POS.sub.-- RF framework of the computer processing system illustrated in FIG. 1. There are many different ways to specify an object-oriented program design, as currently there is no universally accepted scheme of notation. The diagrams used herein will generally follow the model described in Object-Oriented Analysis and Design with Applications, 2d ed. (1994), by Grady Booch, available from The Benjamin/Cummins Publishing Company, Inc., Redwood City, Calif., USA. Use of Booch notation concepts within this specification should not be taken to imply any connection between the inventor and/or the assignee of this patent application and Mr. Booch, his employer, or his publisher. For a more general discussion of object-oriented notation, see Object Oriented Methods, 2d ed. (1994), by Ian Graham, available from Addison-Wesley Publishing Co., Inc., Reading, Mass., USA. Notational concepts used herein generally will be explained as needed.

A system that is modeled by an object-oriented framework can be represented at a high level of abstraction by a diagram called a top-level class diagram. FIG. 6 of the drawings is an example of a top-level class diagram containing boxes that represent abstractions of the POS.sub.-- RF interface. The boxes are arranged in a hierarchy such that boxes representing abstractions close to the physical components of the system are at the lower levels of the diagram and boxes representing more abstract, functional components are closer to the top of the diagram. Thus, in FIG. 6 the higher level is represented by the POS.sub.-- RF box, which represents the overall OOP system that interfaces to existing persistent object services. The components of the POS.sub.-- RF system are represented by the remaining boxes, which are labelled PDS.sub.-- RF, DSM.sub.-- RF, SM.sub.-- RF, PID.sub.-- RF, and RF.sub.-- ADP.

The boxes of FIG. 6 can be thought of as categories comprising groups of similar classes that are defined according to object-oriented programming concepts. Those skilled in the art will appreciate that the categories illustrated in FIG. 6 correspond to object-oriented programming objects that encapsulate data attributes and behaviors, and are stored in the memory illustrated in the block diagram of FIG. 1. Such objects can be implemented, for example, in a computer system operating environment that supports the C++ programming language.

The boxes in a top-level class diagram represent the system abstractions that provide the system behavior. The system abstractions also include classes and objects. Details of the system classes are provided in class diagrams (FIGS. 7-12) that show the class categories and indicate the relationships and responsibilities of the classes. In Booch notation, a class is represented by an irregularly shaped, dashed-line icon commonly referred to a cloud. FIG. 7, for example, shows several classes represented as clouds. Each class is identified by a name that is unique to the associated class category and also indicates the relationship of each class to one of the categories or mechanisms illustrated in FIG. 6.

Because the POS.sub.-- RF framework is designed to interface with an existing persistent object (PO) service, it should be understood that additional objects will be defined by the existing PO service. For example, the preferred embodiment of POS.sub.-- RF defines objects in accordance with the Persistent Object Framework (POF) and interfaces with both POSSOM and CODA. Accordingly, POS.sub.-- RF must receive persistent object references represented by instances of a Persistent Object class. That is, a category diagram of the POF would include the category of Persistent Object, which represents the client object that is a persistent object whose underlying storage representation is a record file.

Returning to FIG. 6, the category boxes include one box labelled POS.sub.-- RF, which is connected to boxes labelled PDS.sub.-- RF, DSM.sub.-- RF, SM.sub.-- RF, PID.sub.-- RF, and RF.sub.-- ADP. In the extended framework the POS.sub.-- RF category is represented by a single object instantiation of a POS.sub.-- RF object that encapsulates the functioning of the POS.sub.-- RF data access system. The POS.sub.-- RF category is shown in FIG. 6 connected to the other categories with straight lines. Those skilled in the art will appreciate that such a connection indicates a simple "association" relationship between categories in which the connected objects share information. Thus, FIG. 6 indicates that the POS.sub.-- RF object shares information with the PDS.sub.-- RF, DSM.sub.-- RF, SM.sub.-- RF, PID.sub.-- RF, and RF.sub.-- ADP objects.

Further details of the object relationships are provided in FIG. 7, which shows the relationships between the objects of each class. In particular, the POS.sub.-- RF object is shown with an "aggregation" relationship to the various POS.sub.-- RF objects. That is, the POS.sub.-- RF system object (representing a particular POS.sub.-- RF system extended from the POS.sub.-- RF framework, with overrides and object extensions) is the whole, which is comprised of PDS.sub.-- RF, DSM.sub.-- RF, SM.sub.-- RF, PID.sub.-- RF, and RF.sub.-- ADP object parts. FIG. 7 shows some exemplary extensions of the POS.sub.-- RF object parts. For example, the DSM.sub.-- RF object is shown with an inheritance relationship to two exemplary subclasses, DSM.sub.-- STRM.sub.-- RF and DSM.sub.-- DDO.sub.-- RF. Those skilled in the art will understand that an inheritance relationship indicates that objects in the DSM.sub.-- STRM.sub.-- RF and DSM.sub.-- DDO.sub.-- RF subclasses will have attributes and operations corresponding to the attributes and operations defined by the DSM.sub.-- RF superclass. The DSM.sub.-- STRM.sub.-- RF class provides processing for streammable data types such as supported by the POSSOM system and the DSM.sub.-- DDO.sub.-- RF class provides protocol processing for data types supported by the CODA system.

FIG. 7 also shows two other inheritance relationships, the RF.sub.-- ADP object has a superclass relationship with two inheritance subclasses RF.sub.-- ADP.sub.-- VSAM and RF.sub.-- ADP.sub.-- LANDP, and the PDS.sub.-- RF object is shown with a superclass relationship to subclasses PDS.sub.-- STRM.sub.-- RF and PDS.sub.-- xxx.sub.-- RF. The RF.sub.-- ADP.sub.-- VSAM objects provide adapter processing to interface directly with VSAM-type datastore, and the RF.sub.-- ADP.sub.-- LANDP objects provide adapter processing to interface directly with LANDP-type datastore. The PDS.sub.-- RF subclass objects provide processing that translates between the persistent object protocol and the underlying datastore. That is, they map persistent object references to the appropriate RF.sub.-- ADP objects. The POS.sub.-- RF object determines which PDS.sub.-- RF subclass should process a particular client request and sends the request to the appropriate PDS.sub.-- RF subclass, which receives the request and correctly processes the protocol before passing the request on to the appropriate RF.sub.-- ADP object.

In FIG. 7, the PDS.sub.-- STRM.sub.-- RF subclass represents processing for streammable data and the subclass PDS.sub.-- xxx.sub.-- RF represents an object that processes another, unspecified "xx" protocol type. Particular subclass objects will be provided by the framework user depending on the intended application and persistent objects to be serviced. Those skilled in the art will be able to provide the subclasses with operations necessary for the intended application, in view of this description, without further description.

FIG. 8 shows the PDS.sub.-- RF object cloud in further detail, illustrating the method or operation names of the PDS.sub.-- RF class. The words "method" and "operation" will be used interchangeably to refer to the processing steps performed by an object of the corresponding class diagram. The Persistent Object Framework with which POS.sub.-- RF interfaces includes a Persistent Object Manager (POM). The PDS.sub.-- RF object provides a uniform interface to the POM by calling the DSM.sub.-- RF object. The POS specification describes five persistent operations, not described herein, implemented by the PDS.sub.-- RF object, which is derived from an abstract class of the POS called PDS. That is, the PDS.sub.-- RF object has attributes and operations defined generally by the PDS class of the POF, but is further specialized by defining the protocol supported by the persistent object and datastore manager. As noted above, these specializations are generally referred to as PDS.sub.-- xxx.sub.-- RF. It should be understood that each specialized PDS.sub.-- xxx.sub.-- RF object will necessitate a corresponding specialized DSM.sub.-- xxx.sub.-- RF object.

The method titles shown in the object diagrams will be listed in accordance with accepted Booch notation, in which method names are shown as a string of uppercase initial words followed by paired parentheses, with the first letter of the initial word in lowercase. Thus, with reference to the methods illustrated in FIG. 8, the processing of the method called checkObjectType() checks to determine if an object is of the correct type for the corresponding PDS.sub.-- xxx.sub.-- RF object. The connect() method is intended as a pass-through to the restore() operation, in recognition that there is currently no clear consensus in the persistent object service community as to the processing implemented by a connect method. The disconnect() method is, in a manner analogous to the connect method, not presently defined and is intended as a pass-through to the store method.

Continuing with the methods shown in FIG. 8, the store() method must be overridden in the framework extension and is implemented in POS.sub.-- RF by calling the addObject() or updateObject() method of the DSM.sub.-- RF class, based on an indicator in the PID of the persistent object. The restore() method must be overridden by the specialized PDS.sub.-- xxx.sub.-- RF objects and is implemented by calling the retrieveObject() method of the corresponding DSM.sub.-- RF class. The delete() method is implemented in POS.sub.-- RF by calling the deleteObject() method of the DSM.sub.-- RF class.

The somInit() and somUnInit() methods shown in FIG. 8 are examples of specialized methods included in the PDS.sub.-- xxx.sub.-- RF objects for initializing and disconnecting, respectively, datastore manager attributes called connectTab, nConnects, and dsm, as specified by the PDS class definition from which PDS.sub.-- RF is derived for the preferred embodiment. Those skilled in the art will appreciate that, depending on the existing persistent object service system with which the POS.sub.-- RF framework invention interfaces, the specialized methods of PDS.sub.-- xxx.sub.-- RF will change or will be different from those shown and described herein.

FIG. 9 shows the methods associated with the DSM.sub.-- RF class objects. The DSM.sub.-- RF class is derived as a subclass of the DSM class defined by the CODA system, the second of the two existing persistent object service systems with which the POS.sub.-- RF framework is intended to interface. Those skilled in the art will appreciate that the particular classes and methods of the DSM.sub.-- RF objects might differ if the CODA system is not one of the systems with which POS.sub.-- RF interfaces. In the preferred embodiment, the DSM.sub.-- RF class implements only the operations of the DSM class from CODA that are needed to permit PDS.sub.-- RF to properly carry out its functions. In particular, the DSM.sub.-- RF supports two types of operations. One type of operation is protocol independent, comprising operations such as connect() and disconnects. These operations are datastore (record file) based and need not be overridden by the subclass extension. The other type of operation is protocol dependent, comprising operations such as addObject() and deleteObject(). These operations are object-based and must be overridden by the specialized DSM.sub.-- xxx.sub.-- RF object extension of the framework, as the process for getting data into and out of an object depends on the protocol used by the object.

In processing, the DSM.sub.-- RF object calls the RF.sub.-- ADP object to implement operations. That is, an RF.sub.-- ADP object will be created for a particular DSM.sub.-- RF and constitutes a record file wrapper to interface underlying file systems to the persistent objects of the client system. The RF.sub.-- ADP object operation is protocol independent. The DSM.sub.-- RF operation always translates object data into a record buffer based on the protocol for which it is specialized. The protocol-independent RF.sub.-- ADP operations are called to perform the data access operations on data in record file storage.

In FIG. 9, the connect() operation is equivalent to an open file or create file process. The input parameter to the operation is PID.sub.-- RF. The DSM.sub.-- RF object looks for a datastoreName attribute in the PID.sub.-- RF object and uses the name to open the file. If the file does not exist, then the DSM.sub.-- RF object will get the schema mapper from the PID.sub.-- RF and use the file specification defined in the schema mapper to create the file. After the file is open, the DSM.sub.-- RF assigns the file handle as the value of the attribute connectID to the PID.sub.-- RF object. Generally, an error flag is indicated if the DSM.sub.-- RF object fails to open or create the file. The disconnect() operation uses a connectID attribute in the input PID.sub.-- RF object to close a record file. The addObject() operation inserts a record into a file and is overridden by the specialized DSM.sub.-- xxx.sub.-- RF object extension for the particular file type. Similarly, the deleteObject() operation deletes a record from a file and is overridden by the specialized DSM.sub.-- xxx.sub.-- RF object.

The updateObject() method indicated in FIG. 9 updates the record in a file to the input object value, for storage into record datastore, and is overridden by the specialized DSM.sub.-- xxx.sub.-- RF. The retrieveObject() method reads a record, for reading a file from record datastore, and is overridden by the specialized DSM.sub.-- xxx.sub.-- RF. The obj2Rec() method performs the transfer of object data into a record and must be overridden by the specialized DSM.sub.-- xxx.sub.-- RF. In an analogous fashion, the rec2Obj() method performs the transfer of record data to the attribute values of a persistent object in the client application and must be overridden by the specialized DSM.sub.-- xxx.sub.-- RF. The getSchemaMapper() method retrieves the name of the schema mapper from the PID information and then causes the instantiation of the schema mapper for use. The findRFAdp() method causes an instance of the RF.sub.-- ADP class in accordance with an environmental variable POS.sub.-- RF.sub.-- ADP.

As noted above, specialized DSM.sub.-- xxx.sub.-- RF objects will be defined for processing of desired data types. The DSM.sub.-- STRM.sub.-- RF shown in FIG. 7 is a specialization of the DSM.sub.-- RF class shown in FIG. 9 and performs processing of streammable data. In particular, a DSM.sub.-- STRM.sub.-- RF object translates between object data and a record data buffer by calling the obj2Rec() and rec2Obj() methods of the DSM.sub.-- RF. As object data is translated into a record buffer, the RF.sub.-- ADP object is called to perform the necessary record operations. In DSM.sub.-- STRM.sub.-- RF, the addObject() method translates object data into a record format by calling the obj2Rec() method, then calls RF.sub.-- ADP to insert the translated record data into the file based on the definition in the corresponding PID.sub.-- RF object. The deleteObject() method in the specialized DSM.sub.-- STRM.sub.-- RF object calls the RF.sub.-- ADP object to delete the record from the file based on the definition in the corresponding PID.sub.-- RF object. The updateObject() method in the specialized DSM.sub.-- STRM.sub.-- RF object translates object data into a record file by calling the obj2Rec() method, then calls RF.sub.-- ADP to update the record in the file based on the definition in the corresponding PID.sub.-- RF object.

The retrieveObject() method of the DSM.sub.-- STRM.sub.-- RF object calls the RF.sub.-- ADP object to read a record into a record buffer based on the definition in the corresponding PID.sub.-- RF object, and then translates the record data into object attribute values for the corresponding persistent object by calling the rec2Obj() method. The obj2Rec() method places object data into a stream data structure by calling a writeToStream() operation of the DSM.sub.-- STRM.sub.-- RF object and then gets an appropriate schema mapper from the PID.sub.-- RF. The obj2Rec() method then calls a strm2Rec() method defined in the schema mapper to place data from the stream data structure into the object. The rec2Obj() method gets the schema mapper from the PID.sub.-- RF object and calls a rec2Strm() method defined in the schema mapper to place the record data into a stream data structure. The rec2Obj() method then calls a readFromStream() method defined in the DSM.sub.-- STRM.sub.-- RF object to place the data into the object.

Another specialized DSM.sub.-- xxx.sub.-- RF object is defined for the dynamic data object (DDO) protocol handled by the CODA system. In the preferred embodiment, the DSM.sub.-- DDO.sub.-- RF is derived from the DSM class of the OMG datastore manager specification that uses DDO as a protocol. That is, the DSM.sub.-- DDO.sub.-- RF is a subclass of the DSM class in the CODA system. To meet record access requirements for CODA, it is necessary to provide DSM.sub.-- DDO.sub.-- RF processing for the DDO protocol. In particular, the interface of DSM.sub.-- DDO.sub.-- RF is much like the DSM.sub.-- STRM.sub.-- RF interface except that the protocol is specified in accordance with the DDO specification. Those skilled in the art will be able to provide the necessary processing operation details, based on the description herein, without further explanation.

FIG. 10 illustrates the operations associated with the SM.sub.-- RF object of the POS.sub.-- RF framework. The SM.sub.-- RF object maps object attribute data into record data according to a predetermined record data format. That is, the developer who extends the POS.sub.-- RF framework designs the SM.sub.-- RF extension according to the record format to be supported. The SM.sub.-- RF object class is necessary for object-to-record data mapping because most records will typically be either fixed-length or variable-length byte strings. Consequently, there is no information maintained in the record datastore that describes the record data format. The operations of the SM.sub.-- RF object are called createDS(), setfSpecField(), setfSpec(), proto2Rec(), and rec2Proto().

The SM.sub.-- RF object operations may be briefly described as follows. The setfSpec() operation is not overridden by the framework user and provides specifications for the supported datastore. The setfSpecField() operation sets the record file field specification by passing parameters for the supported datastore, and is not overwritten by the framework user. The createDS() operation creates a new record datastore by calling the setfSpec() operation a sufficient number of times to fill a field specification array, in accordance with the setfSpecField() operation parameters. The proto2Rec() operation translates data in a protocol into the protocol supported by the POS.sub.-- RF system and is overridden by the framework developer for specific protocols to be supported by the POS.sub.-- RF extension. For example, when SM.sub.-- RF is to support a stream protocol, the proto2Rec() operation allocates space in memory for a record data buffer, then repeatedly uses getSchemaMapper() methods of the DSM.sub.-- STRM.sub.-- RF object to retrieve the values of the attributes and store them into the record buffer, based on the record format specified. The rec2Proto() operation translates data from a record into a protocol. The rec2Proto() operation is overridden by the client for objects that support a specific protocol. For example, when used to support a stream protocol, the rec2Proto() operation first obtains the values of each record field by casting the record with a data structure, obtaining a new stream, and placing the record field data into the stream by using putStream() methods of the DSM.sub.-- STRM.sub.-- RF object. The interaction of these operations will next be described in greater detail.

The SM.sub.-- RF object provides operations to create a new datastore by defining the specifications required to create a file. In the preferred embodiment, SM.sub.-- RF also provides operations that map record data to and from the stream protocol. The mapping between record and stream data must be overridden by the object implementation class based on knowledge of the record format. When a persistent object of a client application invokes an operation, such as restore(), the PID.sub.-- RF object information is passed to the PDS.sub.-- RF object via the Persistent Object Manager of the persistent object service, such as POSSOM or CODA. The PDS.sub.-- RF object implements the restore() operation by requesting the DSM.sub.-- RF object to do a retrieveObject() operation. The DSM.sub.-- RF object gets the persistent object as well as its PID.sub.-- RF object. The DSM.sub.-- RF has an operation called getSchemaMapper() that will get the name of the schema mapper object from the PID.sub.-- RF object and instantiate an instance of the schema mapper.

The DSM.sub.-- RF object also has two operations to transfer data between the object and the record, called obj2Rec() and rec2Obj(). The implementations of these two operations invoke the getSchemaMapper() operation and use the schema mapper operations proto2Rec() and rec2Proto(). To implement the retrieveObject() operation, the DSM.sub.-- RF object invokes the getRec() operation of the RF.sub.-- ADP object to obtain the record data and then invokes the rec2Obj() operation to place the data into the object via the rec2Proto() operation of the schema mapper object. If the DSM.sub.-- RF object is unable to open the datastore file with the file name obtained as an attribute of the PID.sub.-- RF object, then the DSM.sub.-- RF object will invoke the getSchemaMapper() operation and use the createDS() operation to create a new record file. If the createDS() operation is not overridden by the client application, then an error flag will be generated.

The PID.sub.-- RF object operations listed in FIG. 11 are used for identifying the path of persistent object data from the client application. For the POS.sub.-- RF system, any PID.sub.-- RF object must satisfy two assumptions: (1) each persistent object has a unique identifier, and (2) the data of each persistent object is mapped to a record in datastore. The PID.sub.-- RF object illustrated in FIG. 11 includes an operation called updatePIDStream() and an operation called readFromPIDStream(). Thus, a PID.sub.-- RF object defines an access path from a persistent object of a client application to a record file in datastore. Because POS.sub.-- RF is designed to interface with the POSSOM system, the PID.sub.-- RF object is derived from the PID.sub.-- DS object of the POSSOM system that identifies persistent data to be mapped to record datastore. Those skilled in the art will appreciate that the PID.sub.-- RF object would be changed if the extended POS.sub.-- RF framework were intended to interface with a different object-to-record data persistent object service system.

The PID.sub.-- RF object includes an attribute of datastoreName, a full pathname of a datastore file. In the preferred embodiment, a boolean flag called datastoreNew is used to indicate when a new datastore type should be created. An attribute called connectID is a file handle for the datastore record file. A record identifier comprises an attribute called dataID. Finally, a parameter attribute called smMapper is the name of a schema mapper object.

The updatePIDStream() operation of the PID.sub.-- RF object is overridden and places a PID attribute values into a PIDStream object. The readFromPIDStream() operation reads and assigns the values of attributes from the PIDStream object.

FIG. 12 illustrates the operations of the RF.sub.-- ADP object class. An RF.sub.-- ADP object is the object wrapper that maps the DSM.sub.-- RF object to the procedural record file system API. All operations of the RF.sub.-- ADP object must be overridden by the derived class, so that the real implementation is implemented by the specialized adapter. With the definition of the RF.sub.-- ADP, underlying record file systems can be plugged into the POS.sub.-- RF system and, more precisely, the associated Persistent Object Service (POS) systems, without concern for design problems. The RF.sub.-- ADP provides conventional record access operations based on file types. Most record file systems support multiple indexing operations. The design specification of PID.sub.-- RF includes the attribute of indexName and also the attribute of isKey in the fileSpec to support the indexing operations. Additional operations can be provided in the RF.sub.-- ADP object, as desired. The RF.sub.-- ADP operations will next be described. Unless specified otherwise, the operations must be overridden by the specialized record file adapter object.

The openF() operation opens a record file in accordance with an input parameter specified by the PID.sub.-- RF object and in accordance with the datastore to which the persistent object is being mapped. The datastoreName attribute must be set in the PID.sub.-- RF object when the openF() operation is called. The output parameter is called connectID. The specialized adapter controls the access mode for the file open operation. In the preferred embodiment, if the underlying record file system supports file locking, then the file open is shared and a file lock condition will apply for data write operations. If the record file system does not have file locking, then what is known as an exclusive open is applied. The createF() operation creates a record file using the input parameter fileSpec. The closeF() operation closes a file and requires a connectID, also known as a file handle, to be passed as an input parameter.

The getFileSpec() operation retrieves a record file specification for a file, including the file type, record format, and the like. The file is identified by its file name. The getFileStatus() operation gets the status of an open file. The file status might be defined in an object-oriented language as follows in the Table 3 pseudo-code:

The addRecByKey() operation inserts an object into the record datastore based on the key value received. The deleteRecByKey() operation deletes the corresponding record identified by the received input key value. The fetchRecByKey() operation positions the display cursor on the record identified by the received input key value. The getRecByKey() operation returns the record value as an object, based on the received input key value. A lock mode can be implemented to define locks, such as read locks and write locks, as desired. The updateRecByKey() operation replaces the record identified by the received input key with the input object value.

The addRecByRecNum() operation of the RF.sub.-- ADP inserts an object into the record datastore based on a received record number. If the data slot in the file is occupied, then an error flag will be indicated. The deleteRecByRecNum() deletes the corresponding record identified by the input record number. The fetchRecByRecNum() operation positions the display cursor on the record identified by the input record number. The getRecByRecNum() operation reads the record identified by the input record number. A lock mode can be defined to provide read locks for shared data and write locks for exclusive data. The updateRecByRecNum() operation modifies the record identified by the received input record number. The addRec() operation inserts a record to the end of a record file. The deleteRec() operation deletes the record at which the current display cursor is pointed. The getRec() operation reads the record at which the current display cursor is pointed. The updateRec() updates the record at which the current display cursor is pointed, based on the input object value. The fetchRecBOF() operation places the display cursor at the beginning of the record file data.

As noted above, the RF.sub.-- ADP.sub.-- xxx objects will be defined for processing of desired datastore types. FIG. 7 shows two exemplary datastore type processing objects, one called RF.sub.-- ADP.sub.-- VSAM and another called RF.sub.-- ADP.sub.-- LANDP. The RF.sub.-- ADP.sub.-- VSAM is a specialization of the RF.sub.-- ADP class using the "VSAM" record file system by IBM Corporation as the underlying record file system. In the implementation of POS.sub.-- RF, the RF.sub.-- ADP.sub.-- VSAM might be packaged as a separate "vsam.sub.-- adp.dll" class library, the details of which should be apparent to those skilled in the art without further explanation, in view of this discussion. Any other specialized RF.sub.-- ADP object can be implemented similarly as a pluggable class library to be integrated into a "somprf" library. In the preferred embodiment, the operations of the RF.sub.-- ADP.sub.-- VSAM object provide the interface operations between RF.sub.-- ADP and VSAM/x, a record oriented access method on the AIX/6000 system available from IBM Corporation. The operations necessary to provide the interface will be readily apparent to those skilled in the art, in view of this description, without further explanation. Similarly, the RF.sub.-- ADP.sub.-- LANDP is a specialization of the RF.sub.-- ADP class for the "LANDP" record file system as the underlying datastore. Again, those skilled in the art will be able to produce the necessary operations without further explanation, in view of this description.

As described above, the present invention provides a framework for data access between multiple record-oriented data file systems and multiple object-oriented file systems across different protocol types. The framework thereby assists API program developers with the creation and maintenance of object-oriented application programs that can interface with record data files.

The present invention has been described above in terms of a presently preferred embodiment so that an understanding of the present invention can be conveyed. There are, however, many configurations for object-oriented data access frameworks not specifically described herein but with which the present invention is applicable. The present invention should therefore not be seen as limited to the particular embodiment described herein, but rather, it should be understood that the present invention has wide applicability with respect to data access frameworks generally. All modifications, variations, or equivalent arrangements that are within the scope of the attached claims should therefore be considered to be within the scope of the invention.