Persistent State Service

1. Persistent State Service • 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 definition language called PSDL that is much more appropriate for persisting object state than SQL • Persistence is transparent to client Persistent State Service

2. Persistent State Service • 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 Persistent State Service

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

4. Persistent State Service • 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 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 state 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 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 Persistent State Service

7. Persistent State Service • 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. Persistent State Service

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

9. Persistent State Service • 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 Persistent State Service

10. Persistent State Service • Generating Architecture Components • Storage object and storage home incarnations can be generated automatically Storage Home and Storage Type Incarnations (Prog-Lan) PSSDL Compiler Storage Home and Storage Type Specification (PSSDL) Storage Home and Storage Type schema 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 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<Person> spouse; void marry(in ref<Person> the_spouse); }; Abstract storagetype Employee: Person{ state string phone_number; state string office; }; 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 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(); }; }; 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); }; 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; }; 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 Persistent State Service