Transparent and Flexible Storage of Application ...

4 downloads 4345 Views 26KB Size Report
memory content, the system should be able to recover data from persistent storage, i.e., to load persistent data into object attributes. Data integrity and ...
Transparent and Flexible Storage of Application Objects in CORBA Environments Dominik Kuropka, Mathias Weske Westf¨alische Wilhelms-Universit¨at M¨unster Steinfurter Straße 109, 48149 M¨unster, Germany isdoku,weske  @wi.uni-muenster.de   

The ability to store arbitrarily structured objects in persistent storage in a transparent and flexible way with little effort is an important requirement for middleware in general and for object-oriented middleware in particular [1]. This extended abstract describes the demonstration of a transparent and flexible persistence service for application objects in CORBA environments. Details of the conceptual design and the implementation can be found in [3]. The purpose of a persistent storage service is to support application developers in storing object states persistently. In the context of object-oriented applications, a persistent storage service can be represented by appropriate interface definitions and implementations. Generally speaking, at each instance, an object is characterized by its state and its behavior. While object behavior is specified by methods, the state of an object is represented by the object’s current attribute values. Consequently, a persistent storage service deals with storing attribute values persistently, with the aim of enhancing fault-tolerance. If the representation in volatile storage of a persistent object is lost, e.g., due to a server crash, the persistent storage service is responsible for restoring a consistent object state after the system is restarted. This is done by loading the object’s attribute values from persistent storage into volatile storage to reinstall a consistent object state.    

As a basis for the design of the persistent storage service, the following design goals were identified as far as the use of the service is concerned: Ease-of-use, support for class evolution, data integrity, and multi-threading. For efficient software development and maintenance, application programmers, i.e., users of the service, should concentrate on the business logic, rather than on technical details like the persistent storage of application objects. Incurring considerable additional coding to store application objects is not an attractive feature of a persistent storage service. In particular, it seems inappropriate to require application programmers to develop additional interfaces and classes for providing persistence for application objects. In contrast, providing methods for storing object values persistently and for loading object values from persistent storage in volatile storage is a more appropriate choice. Given the dynamic nature of todays business environments, the structure of application objects is likely to change due to new requirements imposed by the application. For example, objects may Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. OOPSLA 2000 Companion Minneapolis, Minnesota (c) Copyright ACM 2000 1-58113-307-3/00/10...$5.00

require new attributes or given attributes are no longer needed. In the former case, the respective attribute values have to be stored persistently to properly represent object states. As a result, it is an important design goal for users of persistent storage service that evolution of both classes and objects is supported. In presence of system failures involving the loss of volatile memory content, the system should be able to recover data from persistent storage, i.e., to load persistent data into object attributes. Data integrity and consistency have long been studied in the context of database systems, where the transaction concept was introduced. In the context of a persistent storage service, writing objects to persistent storage and loading objects from storage should be performed transactionally, i.e., either completely or not at all. Multithreading is used for concurrent activities in application systems. Each thread corresponds to a light-weight process, which may be supported by specific functionality provided by the operating system. Since object-oriented applications typically involve concurrently active objects, a persistent storage service should support multithreading. We mention that multithreading is inevitable if asynchronous execution of methods is required by the application. We stress that within the conceptual design, different implementations are feasible, which may focus on different aspects. Important properties of the service in this context are support for different data repositories, distribution and heterogeneity, as well as different storage policies and data granularities. The design goals are discussed in more detail in [3].  "!#$   

Based on the design goals mentioned, the general structure of the conceptual design is given by the interfaces and the interplay of the respective objects: %

%

Interface PersistentObject: Every persistent object inherits from the PersistentObject interface; it contains the attributes and methods to store objects persistently.

%

Interface Database: The Database interface represents data repositories. In particular, for each data repository used, a database object is created. Hence, incorporating new data repositories amounts to creating new objects of this class. We remark that for each type of data repository, there an implementation of the Database interface is required to capture the specific properties of the system used. Interface Transaction: Represents atomic units of work; in particular, accesses to the data repository have to be executed transactionally. Just as database objects represent data repositories, transaction objects represent database transactions. Again, for each type of data repository, there has to be an implementation of the Transaction interface, to capture the specific properties of data access in the data repository used.

4

Object A persistent Object X 1

5 6

7 Transaction

10 9

2

Database

Data Repository

3 8

Loader

Middleware

Figure 1: Loading Object State from Persistent Storage. The functionality of the persistent storage service is explained by two major tasks that service has to fulfill: storing objects in persistent storage and loading values from persistent storage. To introduce the loading of persistent objects we discuss the steps which are performed to satisfy a request to a persistent object. The objects and their relationships involved in satisfying this request are shown in Figure 1. The request is triggered by an object & calling a public method of persistent object ' , marked by (1) in Figure 1. First we assume that the requested object is in fact available in volatile storage. In this case, the middleware transfers the request to object ' , which processes it and transfers the return values to the calling object. (Notice that this default behavior is not shown in the figure, since it does not involve the persistent storage service.) If, however, persistent object ' is not in volatile storage (2), the current object state of ' has to be loaded from persistent storage. Loading object states from persistent storage is performed by the persistent storage service. In this case, object ' is re-initialized (3). A loader component provided by the object-oriented middleware determines the structure of the persistent object by accessing a database object, which returns the structure of the requested object. This functionality can be provided, for example, by the Persistent Object Adaptor [2]. At this moment, object ' is in the initial state. Due to the object-oriented approach, object ' is responsible for restoring its actual state. To do so, ' requests a transaction from the database object which is used to store ' (4). As indicated above, the database object is a representation of the data repository responsible for storing ' . In general, for each data repository there is one dedicated database object representing that data repository. Once the database object receives the call from ' , it creates a transaction object (5), which is used to retrieve the data from persistent storage. In order to do so, object ' sends a request data message to the transaction object (6), which accesses the data repository to retrieve the attribute values of the requested object ' from the data repository (7). In the next step, the actual values are restored in ' , the middleware component sends the original method request to the now restored object ' (8), which performs the method and returns the values (9) via the middleware to the calling object (10).

objects which can be manipulated by the client using CORBA requests. During the demonstration the audience will experience the complete lifecycle of these persistent objects, i.e., creation and manipulation of objects by method invocation including the delete() method. The recovery features of the service are demonstrated by a simulated server crash. It will be shown that the objects survive the crash unhurt, and each object will be restored to a consistent state on the next access to that object. Finally, a look at the source code of the sample application will show that restoring objects is performed completely transparent for the client. A look at the source code of the server will show how the objects are made persistent by inheriting from the class PersistentObject and by defining synchronization points. We concentrate on persistence issues rather than addressing related issues like interobject transactional support. However, different implementations of the interfaces are feasible. For instance, different object storage models can be implemented, and legacy systems can be used as data stores. The system can be implemented in CORBA environments, using an arbitrary programming language. Our sample implementation uses Java and OrbixWeb. We remark that it can be combined with Common Object Services specified by the OMG, for example the Relationship Service and the Transaction Service. ,

  

This extended abstract describes the demonstration of a persistent storage service for object-oriented middleware. The service is easy to use, since it suffices to inherit from the PersistentObject class in order to make objects of a given class persistent. As explained above, the persistent storage service provides a high degree of extensibility and flexibility, since it supports different data repositories and data representations, even within a given application. By providing the possibility to store specific attributes of objects, i.e., the attributes whose values have changed recently, performance gains can be achieved. While its conceptual design is independent from a specific middleware, a sample implementation uses the CORBA product OrbixWeb. Details of the conceptual design of the service and a sample implementation can be found in [3]. -.0/1.2-.03

,

.#!

[1] Object Management Group: CORBAServices: Common Object Services Specification. OMG Document 98-12-09 1998 [2] OMG: CORBA/IIOP 2.3 Specification. Chapter 11: Portable Object Adaptor. OMG Document formal/99-07-15. OMG 1999 [3] Weske, M., Kuropka, D.: Flexible Persistent Storage Service for Object-Oriented Middleware. Fachbericht Angewandte Mathematik und Informatik 5/2000-I, University of Muenster, Germany 2000

() * + 

The demonstration presents and discusses the specification and implementation of a persistent storage service for the transparent and flexible storage of objects in CORBA environments. An example is prepared to show clearly how the persistent storage service is used and how its works. The example includes a server application as well as a client application. The server provides persistent

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.