Part 2 (A) CORBA and Databases

The World Leader in Making Software Work Together ™1 © IONA Technologies 1998-1999

Part 2 (A)

CORBA and Databases


Background info on CORBA and Databases


Some recent CORBA changes

• POA - portable object adapter

• Servant

• Servant Manager

• Default Servant


Portable Object Adapter

ORB

POA

ORB

This is theconceptual view

of a server!!

..... a set ofCORBA objects

POA : the CORBA component that is responsible for adapting CORBA’s concepts of objects to a programming language’s concept of objects (servants)


Servant

• In a POA ORB, each CORBA object is represented by two objects

– a CORBA object

– a servant object

ORB

POA

CORBA object servant


CORBA objects

• So what are the CORBA objects used for

– .... They must be created so that an object reference can be passed to clients.

– They do not have to physically exist to handle a request ... they are bypassed!

– [ Some programmers like to use IDL interfaces rather than C++/Java/.... Interfaces between the internal components of their servers. They will keep the

CORBA objects in place to handle local calls.]


Servants and Databases

• This a very useful separation from our viewpoint

– the servant can go into the database, while the CORBA object need not.

• Prior to the POA standard within CORBA, ORBs made different server-side choices. Some allowed this separation, while others didn’t.


Details - class hiararchy

CORBA::Object

FrontOffice

Interface FrontOffice {.....};

ServantBase

POA_FrontOffice

FrontOffice_i

IDL

C++

CORBA object

servant


Active Object Map• By default, a POA has an Active Object

Map that records each of the servants that it manages

– maps from ID to servant pointer

ORB

servantsActiveObjectMap

POA


ORB

POA

Servant Activation

• Servants can be deactivated and activated without effecting their accessibility by clients

servant


Details...

ORB

POA

Servant Manager

Objectfault

servant


Object References, Keys and IDs

• Objects are identified as follows:

Reference Key ID

• The ID must be sufficient to locate the servant– e.g., in the database

• The Servant Manager can choose the ID– the “object’s” key in an RDBMS– the object’s identifier in an ODBMS


Kinds of things

Part 2 (B)


Kinds of CORBA objects• Transient CORBA objects

– often their servants don’t have persistent state.– They do not outlive the server process

• they may even have a shorter lifespan– E.g., an iterator over the result of a query– A client cannot safely hold a reference for a long

period of time

• Persistent CORBA objects– Clients can safely hold references for long periods

– they may be static in the server, or incarnated when needed.

Don’t put them in the Naming Service


Kinds of Servants

• Stateful– has application level state

• Stateless– has no application level state

– but may hold a database key

• so it knows what changes to make to the database

– a stateless object can be removed from memory without loosing data


Advantages of Stateless Servants

• They can easily be removed from MM

• The database is updated during each modifying operation call

– so queries against the database will see up to date information

Disadvantages• no caching of data at the application level. We depend entirely on the DBMS


Types of Database Integration• Load objects statically

– these can read/modify data in the DB to initialize themselves, and/or to implement their operations

• A CORBA object loading another from the DB in preparation of an invocation being made on it

• Loading CORBA objects from the DB when invocations are made to them

11

22

33


... Loading (cont)interface FrontOffice {

typedef long BookingID;

BookingID makeBooking (.....);

};

interface Booking {.....};interface FrontOffice {

Booking makeBooking (....);};

FrontOffice - statically load.Booking - Load objects when they are invoked upon.

interface Booking {.....};interface FrontOffice {

Booking makeBooking (.....);Booking getBookingByID (....);

};

Statically load the FrontOffice object

FrontOffice - statically load.Booking - load objects in getBookingByID. - make them transient CORBA objects.


Use of POAs

Part 2 (C)

• POAs allow you to create high performance and scalable systems

• Smaller systems will make very simple use of POAs


POA’s Active Object Map

• Recall the default way that objects are found:

ORB

servants

ActiveObjectMap

POA

Loo

kup


Introduce a Servant Manager

• ... to handle object faults by activating the servant

ORB

servants

ActiveObjectMap

POA

Servant Manager(Servant Activator)

Loo

kup

Loo

kup

fails


ORB

servants

Servant Manager(Servant Activator)

POA

The Servant Manager may use a table of some sort to find the servants or it may be able to find them in some other way.

... But the Active Object Map may be inappropriate

• Select a policy that removes it:


Eviction

• Servants can be deactivated when the invocation is finished

• or they can stay activated

– ... and be deactivated later

–e.g., if the server is running out of memory then some servants can be chosen to be evicted

• This is easier for stateless servants.


Evictor Pattern

• Record all of the currently loaded servants.

• Load a servant on demand– but remove an existing one if you don’t have

the space to load the newly required one

• Use some “victim selection algorithm”

– e.g., fixed size pool, and LRU• If the Servant Manager maintains the Object Map then it can

implement the Evictor Pattern itself

– if the POA maintains its Active Object Map then the servants must also be involved in the pattern implementation


Could we survive with just one Servant

• Use a “default servant” .... a catch all

ORB

Default servant

POA

POA’s Active Object Map is optional.

The default servant uses POA calls to determine the identify of the target object -- and assumes it’s identify for the duration of the call (or passes the call to another object to handle it).


Multiple POAs• you can have multiple POAs per address space

• Each POA represents a grouping of objects with similar characteristics

• Each POA has a policy that controls– whether an active object map is maintained– servant manager or default servant or neither– ID management: application or system– thread allocation : single or multi– transient or persistent CORBA objects– etc.

• E.g., you may have a POA per DB;

– or per type; etc


An aside : BOA ORBs

• Similar support, but it’s proprietary

• Orbix 3

– Uses loaders/filters to write object adapters

• allocate object keys

• handle object faults

• control transactions (if OTS isn’t used)


Databases not just Persistent Stores

• So far, much of what we have said relates to Persistent Stores as much as it does to DBMSs

• For DBMSs, we must add support for

– queries

– transactions


Queries

• Affect the caching mechanism

– if we cache data in MM objects, and we don’t have exclusive access to the DB

• then we need to flush the data at the end of each transaction

• (also after each update if the server itself wants to make a query)


Transactions

• The OTS (Object Transaction Service) will co-ordinate commits across multiple DBs.

• You can also introduce your own Resource Manager to co-ordinate rollbacks to cached data

– and register this with the co-ordinator.

– This is real rocket science stuff.


Why integrate CORBA and Databases?

Part 2 (D)


CORBA and Databases• There are two views of why CORBA and

Databases need to be integrated

– from the CORBA viewpoint

– from the Database viewpoint

• From the CORBA viewpoint

– There is an obvious need to store the data of FrontOffice objects in some database

• so that the current state of the bookings for the theater can be recorded

11


From the Database viewpoint• From the Database viewpoint

– You wish to gain the benefits of CORBA• ease of working across operating systems• ease of working across programming

languages• ease of programming distributed systems• messaging technology• legacy system integration• tight connection to Windows OLE• standards based distribution• light-weight clients

22


Distributed ODBMS• Some DBMSs do not support distribution

• But many do– this support for distribution is different to the CORBA model

• in fact they compliment each other very well.

Data transfer

ClientApplicationMachines

StorageMachine(s)

Distributed Object DBMS


Issues• Can the clients run on small machines?

• Will the system scale if the data contention between clients is high?

• Will it run over a WAN?• Is the complexity of the data manipulation at the client sufficient

to justify the data transfer to the client?• Is it OK to write all of the clients in the same programming

language?(or the few languages supported by the chosen OODBMS?)

• Can the clients be written to closely tie-in with OLE?– can we access the database from VBA in Excel?

• Can you bridge all boundaries?– A stock exchange wants to publish an interface

• and not say how it is implemented

Q


Light-weight Clients using CORBA

Data transfer

ClientApplicationMachines

StorageMachine(s)

– clients send operation invocations– all of the advantages of CORBA (bridging

boundaries; interfaces; msg; standards; . . . )– you are publishing interfaces, not

implementations

CORBAServers-- direct access to data

Operation calls


Distributed RDBMS

SQL queries

SQL queriesexecutedin clients

Data transfer

Same advantage of adding CORBA as with ODBMS:• bridging boundaries• exposing interfaces, not implementations• we are not exposing a database schema• messaging technologies, etc.

or


Light-weight Clients - summary

SQL queries or data transfer

Operation calls

Distributed RDBMS

The clients don’t even know if we are using a RDBMS or ODBMS !

Data transfer

Operation calls

Distributed ODBMS

CORBA servers

clients

StorageMachine(s)


Storing objects in RDBMS : 4 tasks• decide on the mapping from OO view to relational view

• implement this mapping• load objects on the fly• if data is cashed in objects then

– flush the cache when a transaction commits• and discard it when a transaction aborts

– or may have to write-through on each modification.


Code Generation

Part 2 (E)


Code Generation• Relational schema

C++ classes

IDL interfaces

• “ Do it by hand! “ -- no way!

• Won’t it be nice to push a button to generate the code to go from schema to IDL.

• Fine -- but be warned that the results mightn’t be very pleasing


Consider the following tables

• What IDL would you get?

BookingID Date BookingID SeatNum

BookingDate BookingSeat


Perhaps ....typedef long BookingID;

interface BookingDate {

attribute BookingID theBookingID;

attribute Date theDate;

};

interface BookingDateMng {

// operations to create and delete “rows”

};

interface BookingSeat {

// definition of SeatNum;

attribute BookingID theBookingID;

atrtribute SeatNum theSeatNum;

};

interface BookingSeatMng {

//operations to create and delete “rows”

};


What happened our Business Object layer?

• ... with operations such as

makeBooking( .... );

getBookingByName ( .... );

• Code generation (schema IDL) is very useful but typically the code should be encapsulated by a higher layer within the server

– so schema C++ or Java may be just as useful.


CRUD• schema IDL automatic code generation can

be useful for very simple systems– for so called CRUD interfaces

–Create–Read–Update–Delete

• but the interface exposed to clients will be very low level [no usage patterns !!] and it may perform badly . . . .

See over...


Always be careful of “data objects”

• Consider a table with many fields

• The auto-generated IDL is likely to provide separate operations to retrieve each field.

• ... an order of magnitude slower than retrieving all in one call.


What about the other direction ?

• IDL relational schema

• The issue is that IDL doesn’t define data members

– it defines operations and attributes, but attributes need not correspond to data members

• In CORBA, PSS is one way to tackle this ...


PSS

• Persistent State Specification - one of the CORBA services.

• It helps you to implement servants that have persistent state.

– The fact that PSS is used in a server is not visible outside of the server.

– PSS is of no concern to clients.


PSS (cont)• PSS defines a new language, PSDL

– Persistent State Definition Language– you can specify state

• independent of the chosen programming language

– It’s a superset of IDL• adds syntax to specify state, keys, etc.• Or can specify the persistent state in C++

or Java.• PSS defines operations to flush memory, refresh

a cache, load objects by key. It supports embedded objects, references, ...


C++/Java relational schema

• There are many commercial products that do this

– and some provide extras such as caching

• These can be directly used by a CORBA application

C++ layer

RDBMS

IDL layer CORBA objects

Servants

Tables


Persistence in EJB

• An EJB impl can automate a lot of the work

– <the standard doesn’t say how>

• For example, a combined CORBA + EJB system

Java layer

RDBMS

IDL layer CORBA objects

Servants

Tables

Automatic, but may have to be enhanced by the programmer.

Automatic, just implement the business logic


Automatic Mapping - summary

• there are many mapping techniques– Relational C++ / Java– Relational IDL– PSDL Java implementation on

RDBMS– PSDL C++ implementation on

RDBMS– Java relational with automated support

for CORBA + EJB layer


(cont)• Use these automatic code generators, but invest

the freed time at the design level– and be prepared to augment the results

• Remember than none of these mapping techniques remove the need for proper IDL design– the client interface must be easy for clients to

use, and it must perform well with the typical usage pattern.

• None of them remove the need for a proper business object layer

Documents

Part 2 (A) CORBA and Databases