1. Persistent State Service 1  Concept  Persistence is the ability of an object state to survive termination of the process in which the object executes  State objects have attributes in their interfaces, and instance variables in their implementation  Stateless objects  Server object designer/programmer implement persistence  Persistent state service hide the details of data stores from server objects  PSS is not an interface to a complete, object-oriented database management system  PSS offers an OO data definiton language called PSDL that is much more appropriate for persisting object state than SQL  Persistence is transparent to client

2. Persistent State Service 2  Concept  Object states, a conflict with encapsulation?  Need for persistence  Persistence-related details of data model without implementation language specific features  PSDL (Persistent State Definition Language), declarative, independent of a data store  Super set of IDL  Second layer of abstraction between abstract interface and concrete implementation  PSDL compiler  Datastore  Storage homes  Storage home incarnation  Storage objects  Storage object incarnations  Catalog

3. Persistent State Service 3  Concept DataStore Storage Objects Storage Homes Storage Object Incarnation Storage Home Incarnation Sessions Catalog

4. Persistent State Service 4  Concept  Datastores are storage technologies that are used to achieve persistence of data.  Storage types define the representation of storage objects  Storage type specifications are interfaces to storage objects  A storage object incarnation is a programming language representation of a storage object  A storage home manages the life cycle of types of storage objects. Its interfaces defined in a storage home specification  Storage home incarnations are programming language representations of storage homes.  A key is an attribute of a storage object that uniquely identifies the storage object within its storage home.  A session is a logical connection between a datastore and a process that executes a server object

5. Persistent State Service 5 Storage Objects  Storage objects  Have types declared statically in PSDL  Have individual identities  Resides in storage homes  Globally accessible  Not CORBA objects, cannot be accessed using CORBA invocations  represent the persistent sate of individual CORBA objects, with which they are associated  Client representative  Storage object instance  Storage object instance can be connected to a storage object in the datastore  incarnation: changes affect the data in the datastore  Can be disconnected

6. Persistent State Service 6 Storage Homes  Storage homes  Have types declared statically in PSDL  For any given type, there can be only a single storage home within a datastore  For any storage home, it contains storage object of one type only  For any given storagetype, there can only be a single storage home in a datastore  Storage homes and storage objects live in datastores  Storage home client representative  Instance  Incarnation  Catalogs  Scope for storage homes  Client representative of datastore  Can be defined in PSDL

7. Persistent State Service 7  CORBA Persistent State Service  PSSDL  Superset of IDL  Extends IDL with mechanisms to specify storage objects, storage homes and keys  Transparent to client  Programming language bindings: storage home and storage object specifications are mapped to java interfaces.  Server object programmer subclass the generated classes to add specific behavior  Integration with Object Adapter  Storage home keys can be used in CORBA object identifiers.  Multiple storage objects can be executed in one server process.

8. Persistent State Service 8  Persistent State Service Architecture Connection & Session Management API Server Object Implementation Storage Object Incarnations & Storage Home Incarnations Datastore AP Storage Object & Storage Home Schema Datastore Run-Time

9. Persistent State Service 9  Architecture Components and Their Interactions  Datastore APIs are independent of storage types  Session management of the persistent state service has to be integrated with the session management of the datastore  A schema is a type definition of information that is defined in a language specific to the datastore  Server object implementations are independent of schemas and thus not dependent on particular datastore technology  Storage object and storage home implementations are dependent on datastore technology

10. Persistent State Service 10 Persistent State Service  Generating Architecture Components  Storage object and storage home incarnations can be generated automatically PSSDL Compiler Storage Home and Storage Type Specification (PSSDL) Storage Home and Storage Type Incarnations (Prog-Lan) Storage Home and Storage Type schema

11. Persistent State Service 11 Persistent State Service  Datastore Technology for Persistence  Persistence in file systems  CORBA externalization service: standardize interfaces that enable CORBA objects to write their state into a sequential byte stream and to read the state from the byte stream.  No concurrency control and transactional access  Persistence in relational databases  Mapping objects into tables  Object-relational mappings are complicated due to the mismatch rational and object-oriented paradigms  Persistence in object database

12. Persistent State Service 12 The Persistent State Definition Language  Declarative language  Stateful, non-CORBA object  Superset of IDL  Abstract storagetypes // file: employee.psdl Abstract storagetype Person { state string full_name; readonly state long ssn; readonly state ref spouse; void marry(in ref the_spouse); }; Abstract storagetype Employee: Person{ state string phone_number; state string office; };

13. Persistent State Service 13 The Persistent State Definition Language  Embedded storagetype: state member itself is a storagetype  Reference types: state member references to other storagetypes  Operations declared in an abstract storagetype follow the same rule as the operations in IDL interface  Arguments must be storagetypes  Storagetypes can inherit from each other  The base is CosPersistentState

14. Persistent State Service 14 CosPersistentState Module CosPersistentState{ typedef CORBA::OctetSeq Pid; typedef CORBA:OctetSeq ShortPid; abstract storagetype StorageObject { void destroy_object(); // associated object is destroyed, not the incarnation bolean object_exists(); Pid get_pid(); ShortPid get_short_pid(); StorageHomeBase get_storage_home(); };

15. Persistent State Service 15 Abstract Storage Homes abstract storagehome PersonHome of Person { factory create_person(in string name, in long ssn); key ssn_key social_security_number; }; abstract storagehome EmployeeHome of Employee: PersonHome{ factory create_employee(in string name, in long ssn, in string phone, in string office); };

16. Persistent State Service 16 Catalogs  Catalogs are the units of session management in the PSS  Applications access datastores through sessions  Catalogs define the scope of a session in terms of the storage homes that can be accessed  Catalogs can define local operations catalog HumanResources { provides PersonHome persons; provides EmployeeHome employees; };

17. Persistent State Service 17 Key Points  Stateless and stateful server objects  Persistence only needs to be implemented for stateful server object  Persistence is transparent to client  Persistence state service keeps implementation of persistence independent of datastore  PSDL  File, relational db, oo db for store object state