Using an Object Reference Approach to Distributed Updates

1
Using an Object Reference Approachto Distributed
Updates

• Dalen Kambur
• Interoperable Systems Group,
• Dublin City University

2
Content

• Background and Motivation
• Related Research
• ORef Model
• ORef Architecture and positioning of Object Pool
  Pairs (OPPs)
• Principles behind an Object Pool Pair (OPP)
• Prototype
• Conclusions and Further Research

3
Background and Motivation

• Our research is a part of the EGTV Project that
  focuses on issues of
• replacing centralised and specialised multimedia
  stores with general-purpose object databases,
  where
• databases are customised for different target
  user groups, and
• integration of such databases.
• These databases are heterogeneous specifically
  with regards to multimedia operations, as
• different built-in types for different databases,
  and
• different user requirements result in different
  multimedia types and operations.
• Hence the target architecture is federated, and
  we must provide a single interface to the data,
  which must support defining operations
• to facilitate integration, and
• to provide optimisation of queries to provide
  searching capabilities.
• Object-Reference model is used as the canonical
  model.
• Industrial standards (ODMG, SQL1999, CORBA PSS)
  are not suitable.

4
Related Research

• LOQIS introduced the concept of references,
  however database federations not addressed as
  such.
• IRO-DB used similar technology (CORBA , ODMG),
  however had full encapsulation as issue.
• MOOD also used similar technological approach
  (dynamic libraries) but no theoretical model.
• COCOON dealt with issues of object-preserving
  semantics however focused only on COCOON
  databases.
• MultiView introduced object-slicing but was
  focused purely on GemStone/SmallTalk.

5
ORef Model

• Designed as a part of the Efficient Global
  Transactions for Video (EGTV) project at the
  Dublin City University
• An object-oriented model used to integrate
  multimedia data.
• Enhanced with the paradigm of references which
  provide addressing of both objects and properties
  in the model.
• References are used to connect the operations and
  object and properties by
• passing target object and parameters using
  references, and
• passing return value using a reference,
• hence facilitating stored behaviour.
• References are also used to define the semantics
  of query languages, which is a part of the model
  definition.
• References are the basis of relationships.

6
ORef Architecture

• Based upon federated database architecture.
• Uses the ORef model as the canonical model.
• Data in component databases integrated as objects
  using an Object-Pool Pair mechanism
• Non-object databases data first transformed
  into objects using object wrapers
• ODMG
• SQL1999
• An ORef Node as a component database

7
Object Pools in the ORef Architecture
Basic deployment
Provides objects to
ORef Client Application
Client Applications Object Pool
Client Application
OPP A
A
ORef Server
Servers Object Pool
Query Processor, Behaviour
OPP B
B
ODMG
Servers Object Pool
8
Object Pools in the ORef Architecture
Federated deployment
ORef Client Application
ORef Server
ORef Server
ORef Server
ORef Server

ODMG
SQL1999
Other DBs
9
Contents

• Background and Motivation
• Related Research
• ORef Model
• ORef Architecture and positioning of Object Pool
  Pairs (OPPs)
• Principles behind an Object Pool Pair (OPP)
• Prototype
• Conclusions and Further Research

10
An Object Pool Pair

• is created either for
• a client application, or
• an ORef Server i.e. query processor or
  behaviour.
• consists of
• the Local Object Pool, and
• the Remote Object Pool.
• provides objects using the following three
  functions
• materialising objects importing into object
  pool,
• propagating updates to make objects are
  current, and
• disposing objects once no longer needed
• to which references are crucial.

11
Reference Types

• A reference is either
• Local, containing the orefOID of the materialised
  object (901)
• Neighbour, containing the sourceOID of the
  pointed object in connected object pool (A,801)
• Remote, containing the sequence of object pools
  to traverse to reach the object from the first
  connected, and objects sourceOID ((A,B), 101)

ORef Client Application
901
A
ORef Server
801
B
ODMG
101
12
Processing Principles

• Any update will always be located in a single
  object pool pair
• when modifying properties, the local OP, and
• when invoking modifiable behaviour, the remote
  OP.
• Any object may be materialised at most once in a
  single object pool.
• Required as otherwise two materialisations of the
  same object would no longer have same object
  identifier hence would not be identical!
• Properties of a single object must have the same
  value when accessed in any object pool.
• Clear consistency requirement. However,
• It allows to postpone propagating updates and
  apply in batches.

13
Preserving Consistency

• An Object Pool Pair preserves consistency using
• a register of materialised objects
• contains the orefOIDs of materialised objects,
  and
• is indexed for fast-searching using the
  sourceOID.
• a set of modified objects
• contains the orefOIDs of modified objects

14
Materialising objects

• An object pointed by
• a local reference is materialised,
• a neighbour reference (poolID, sourceOID)
• the register of materialised objects is checked
  for sourceOID
• if found, the neighbour reference transformed to
  local using found orefOID completing the
  materialisation
• if not found, the object is read through the
  Object Pool Pair identified by poolID
• Values of properties that do not contain
  references are copied with no modifications, and
• Values of properties that contain references are
  adjusted to include identifcation of their source
  Object Pool Pair,
• Newly materialised object is placed in the
  register to prevent further materialisations of
  the same object.

15
Materialising objects continued

• A remote reference (listOfPools, sourceOID)
• A new reference is constructed by removing the
  connected Object Pool Pair from the list, and the
  sourceOID
• This new reference is materialised in the
  connected Object Pool Pair. This initiates either
  
• a neighbour reference materialisation that
  prevents multiple materialisations, or
• a remote reference materialisation that further
  initiates
• a remote reference materialisation, or
• a neighbour reference materialisation.
• Furthermore, as the neighbour reference
  materialisation ensures that each object is
  materialised only once per object pool, the
  remote reference materialisation process has the
  same characteristic.

16
Propagating Updates

• The State Transition Diagram

17
Propagating Updates continued

• To Synchronise from Local Current
• using the set of modified objects, extract the
  sourceOIDs from the objects,
• copy values of properties that are not
  references, and
• adjust the properties that contain references to
  remove the last object pool pair and copy as
  such.
• To Synchronise from Remote Current
• use a union of all sets of modified objects as
  the set of modified objects, and
• send to the Local Object Pool to re-read all
  listed objects.

18
Performance Characteristics of an OPP

• Objects are materialised
• at request no overhead associated with
  maintaining unused objects
• only once and
• only the reference that requested materialisation
  is transformed into a local reference no
  overhead associated with updating all references.
• Updating objects
• updates are accummulated and applied in batches
  no network latency associated overhead

19
Prototype

• The similarily between orefOIDs and memory
  addresses used extensively to simplify coding.
• Common functionality of the prototype coded as
  C templates for faster coding.
• ORef built-in types manually coded as C
  classes.
• C classes generated for ORef user-defined
  types.
• Behaviour stored in DLLs, and loaded at request.
• CORBA used for transport to ensure platform
  independence.
• Functionally complete.
• Built on Windows XP using Microsoft Visual C
  2003, Versant ODMG database and OmniORB CORBA.

20
Conclusions Further Research

• The Object Pool Pairs are the basis of the
  communication in the ORef Architecture
• designed to support integration using ORef Model,
• based upon features of the ORef Model, and
• designed to eliminate unneeded processing and
  network latencies.
• Future research
• A proper benchmarking of applications as the
  prototype is functionally complete.
• Partial materialisation
• Alternatives to CORBA?

21
Thank you

• Questions?