Persistent State Service 2.0 orbos980802 Revised Joint Submission INPRISE Corporation Objectivity In

1
Persistent State Service 2.0orbos/98-08-02Revis
ed Joint SubmissionINPRISE CorporationObjectivi
ty Inc.Secant Technologies Inc.Sun Microsystems
Inc.with collaboration and support fromArdent
Software Inc.Novell Inc. Object Design
Inc.Poet Software Inc.Versant
CorporationWindward Solutions Inc.
EditorsDr. Jeff Eastman (jeff_at_windwardsolutions.c
om)Dr. Robert Hirschfeld (hirschfeld_at_windwardsolu
tions.com)
2
Submission Benefits

• Widest variety of objects that can be persistent
• Efficient support for the widest range of
  datastores
• Most flexible interface between ORBs and PSs
• Best OMG citizen
• Easiest to use

3
Comparison with orbos/98-9-03

• We are a superset
• Three areas where we excel
• an architecture rather than a demo
• actually have a persistent storage component
• any object can be persistent

4
Service Model

• Incarnations are projections of persistent
  objects
• native programming language objects
• one incarnation per persistent object per
  transaction
• Persistent objects may be defined in many ways
• valuetype declarations
• programming languages
• other definition languages
• vendor-specific tools
• Servant-Incarnation mappingis the domain of PSS

5
Use Models

• All eight types of servants are supported

1 type per servant
n objects per type
1 object per type
1 incarnation per object
n incarnations per object
6
Persistent Store

• PS component supports four interfaces
• Locator Management
• ORB connection
• Incarnation Management
• finding incarnations
• Name Management
• persistent directory
• Lock Management
• managing sharing
• OTS transactions

7
Request Processing

• Three transaction control modes
• implicit
• explicit
• automatic
• Three transaction demarcation points
• at client implicit
• at ServantLocator automatic
• at Servant or Incarnation explicit
• All involve association of transactions with
  threads via CosTransactionsCurrent

8
Persistent CORBA Objects

• The find process
• incarnating persistent objects by pid
  transaction
• transitive closure clustering issues
• Assignment
• ensure transaction compatibility
• Traversing object references
• local can use language mechanisms
• CORBA need ORB intervention

9
Illustrative Examples

• Examples of ServantLocators

1 type per servant
n objects per type
1 object per type
1 incarnation per object
n incarnations per object
10
Detailed Java Examplesent to pss-eval_at_omg.org

• A working Java implementation of the IONA HR
  example that demonstrates
• PS population, server setup, client access
• transparent persistence
• transparent transaction management
• PS support for persistence by reachability
• PS support for Servant Locator developers
• OTS, ObV, POA compatibility

11
Comparison with orbos/98-08-03

• Three areas where we excel
• separation of concerns
• OTS transactions and PSS persistence are
  orthogonal
• supports more types of servants and servant
  locators
• persistent storage component
• component-style interfaces provide all PSS
  services
• exploits OTS affinity between threads and
  transactions
• incarnation management find made explicit
• object independence
• any object can be persistent, not just valuetypes
• standard language mappings, object services
• transparent object persistence

12
Submission Benefits

• Widest variety of objects that can be persistent
• not just valuetypes, any object can be persistent
• includes many existing applications and libraries
• Efficient support for the widest range of
  datastores
• supports relational, object, object-relational,
  file based
• Most flexible interface between ORBs and PSs
• 8 ORB-persistent store configurations, not just 2
• Best OMG citizen
• no changes required to existing specifications
• Easiest to use
• transparent transactions and persistence make
  deploying persistent applications straightforward