Transcript POA

Part 2 (A)
CORBA and Databases
1
© IONA Technologies 1998-1999
The World Leader in Making Software Work Together ™
Background info on CORBA and Databases
2
© IONA Technologies 1998-1999
The World Leader in Making Software Work Together ™
Some recent CORBA changes
•
•
•
•
3
POA - portable object adapter
Servant
Servant Manager
Default Servant
© IONA Technologies 1998-1999
The World Leader in Making Software Work Together ™
Portable Object Adapter
This is the
conceptual view
of a server!!
POA : the CORBA component that is responsible for adapting
CORBA’s concepts of objects to a programming language’s
concept of objects (servants)
..... a set of
CORBA objects
POA
ORB
4
© IONA Technologies 1998-1999
ORB
The World Leader in Making Software Work Together ™
Servant
• In a POA ORB, each CORBA object is
represented by two objects
– a CORBA object
– a servant object CORBA object
servant
POA
ORB
5
© IONA Technologies 1998-1999
The World Leader in Making Software Work Together ™
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.]
6
© IONA Technologies 1998-1999
The World Leader in Making Software Work Together ™
Servants and Databases
• This a very useful separation from our
viewpoint
– the servant can go into the database,
while the CORBA object need not.
•
7
Prior to the POA standard within CORBA, ORBs made different server-side
choices. Some allowed this separation, while others didn’t.
© IONA Technologies 1998-1999
The World Leader in Making Software Work Together ™
Details - class hiararchy
Interface FrontOffice {
.....
};
IDL
servant
ServantBase
CORBA object
C++
8
CORBA::Object
POA_FrontOffice
FrontOffice
FrontOffice_i
© IONA Technologies 1998-1999
The World Leader in Making Software Work Together ™
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
Active
Object
Map
servants
POA
ORB
9
© IONA Technologies 1998-1999
The World Leader in Making Software Work Together ™
Servant Activation
• Servants can be deactivated and activated
without effecting their accessibility by
clients
servant
POA
ORB
10
© IONA Technologies 1998-1999
The World Leader in Making Software Work Together ™
Details...
servant
Servant Manager
Object
fault
POA
ORB
11
© IONA Technologies 1998-1999
The World Leader in Making Software Work Together ™
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
12
© IONA Technologies 1998-1999
The World Leader in Making Software Work Together ™
Kinds of things
Part 2 (B)
13
© IONA Technologies 1998-1999
The World Leader in Making Software Work Together ™
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
14
© IONA Technologies 1998-1999
The World Leader in Making Software Work Together ™
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
15
© IONA Technologies 1998-1999
The World Leader in Making Software Work Together ™
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
16
© IONA Technologies 1998-1999
The World Leader in Making Software Work Together ™
Types of Database Integration
1
2
3
17
• 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
© IONA Technologies 1998-1999
The World Leader in Making Software Work Together ™
... Loading (cont)
interface FrontOffice {
Statically load the FrontOffice object
typedef long BookingID;
BookingID makeBooking (.....);
};
FrontOffice - statically load.
Booking
- load objects in getBookingByID.
- make them transient CORBA objects.
interface Booking {.....};
interface FrontOffice {
Booking makeBooking (.....);
Booking getBookingByID (....);
};
interface Booking {.....};
interface FrontOffice {
Booking makeBooking (....);
};
18
© IONA Technologies 1998-1999
FrontOffice - statically load.
Booking
- Load objects when they are
invoked upon.
The World Leader in Making Software Work Together ™
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
19
© IONA Technologies 1998-1999
The World Leader in Making Software Work Together ™
POA’s Active Object Map
• Recall the default way that objects are found:
servants
Lookup
Active
Object
Map
POA
ORB
20
© IONA Technologies 1998-1999
The World Leader in Making Software Work Together ™
Introduce a Servant Manager
• ... to handle object faults by activating the servant
servants
Lookup
Active
Object
Map
Servant Manager
(Servant Activator)
POA
ORB
21
© IONA Technologies 1998-1999
The World Leader in Making Software Work Together ™
... But the Active Object Map
may be inappropriate
• Select a policy that removes it:
servants
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.
Servant Manager
(Servant Activator)
POA
ORB
22
© IONA Technologies 1998-1999
The World Leader in Making Software Work Together ™
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.
23
© IONA Technologies 1998-1999
The World Leader in Making Software Work Together ™
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
24
© IONA Technologies 1998-1999
The World Leader in Making Software Work Together ™
Could we survive with just one Servant
• Use a “default servant” .... a catch all
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).
Default servant
POA
ORB
POA’s Active Object Map is optional.
25
© IONA Technologies 1998-1999
The World Leader in Making Software Work Together ™
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
26
© IONA Technologies 1998-1999
The World Leader in Making Software Work Together ™
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)
27
© IONA Technologies 1998-1999
The World Leader in Making Software Work Together ™
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
28
© IONA Technologies 1998-1999
The World Leader in Making Software Work Together ™
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)
29
© IONA Technologies 1998-1999
The World Leader in Making Software Work Together ™
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.
30
© IONA Technologies 1998-1999
The World Leader in Making Software Work Together ™
Why integrate CORBA and
Databases?
Part 2 (D)
31
© IONA Technologies 1998-1999
The World Leader in Making Software Work Together ™
CORBA and Databases
• There are two views of why CORBA and
Databases need to be integrated
– from the CORBA viewpoint
– from the Database viewpoint
1
32
• 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
© IONA Technologies 1998-1999
The World Leader in Making Software Work Together ™
From the Database viewpoint
2
33
• 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
© IONA Technologies 1998-1999
The World Leader in Making Software Work Together ™
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.
Distributed Object DBMS
Client
Application
Machines
Data transfer
Storage
Machine(s)
34
© IONA Technologies 1998-1999
The World Leader in Making Software Work Together ™
Issues
Q
35
• 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
© IONA Technologies 1998-1999
The World Leader in Making Software Work Together ™
Light-weight Clients using CORBA
Client
Application
Machines
Operation calls
CORBA
Servers
-- direct access to data
Data transfer
Storage
Machine(s)
– clients send operation invocations
– all of the advantages of CORBA (bridging boundaries;
interfaces; msg; standards; . . . )
– you are publishing interfaces, not implementations
36
© IONA Technologies 1998-1999
The World Leader in Making Software Work Together ™
Distributed RDBMS
or
SQL queries
executed
in clients
SQL queries
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.
37
© IONA Technologies 1998-1999
The World Leader in Making Software Work Together ™
Light-weight Clients - summary
Distributed RDBMS
Distributed ODBMS
clients
Operation calls
Operation calls
CORBA servers
SQL queries
or data
transfer
Data transfer
Storage
Machine(s)
The clients don’t even know if we are using a
RDBMS or ODBMS !
38
© IONA Technologies 1998-1999
The World Leader in Making Software Work Together ™
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.
39
© IONA Technologies 1998-1999
The World Leader in Making Software Work Together ™
Code Generation
Part 2 (E)
40
© IONA Technologies 1998-1999
The World Leader in Making Software Work Together ™
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
41
© IONA Technologies 1998-1999
The World Leader in Making Software Work Together ™
Consider the following tables
BookingDate
BookingID
BookingSeat
Date
BookingID
SeatNum
• What IDL would you get?
42
© IONA Technologies 1998-1999
The World Leader in Making Software Work Together ™
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”
};
43
© IONA Technologies 1998-1999
The World Leader in Making Software Work Together ™
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.
44
© IONA Technologies 1998-1999
The World Leader in Making Software Work Together ™
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...
45
© IONA Technologies 1998-1999
The World Leader in Making Software Work Together ™
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.
46
© IONA Technologies 1998-1999
The World Leader in Making Software Work Together ™
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 ...
47
© IONA Technologies 1998-1999
The World Leader in Making Software Work Together ™
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.
48
© IONA Technologies 1998-1999
The World Leader in Making Software Work Together ™
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, ...
49
© IONA Technologies 1998-1999
The World Leader in Making Software Work Together ™
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
IDL layer
CORBA objects
C++ layer
Servants
RDBMS
50
© IONA Technologies 1998-1999
Tables
The World Leader in Making Software Work Together ™
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
IDL layer
CORBA objects
Java layer
Servants
Automatic, just
implement the business
logic
Automatic, but may
have to be enhanced by
the programmer.
RDBMS
51
© IONA Technologies 1998-1999
Tables
The World Leader in Making Software Work Together ™
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
52
© IONA Technologies 1998-1999
The World Leader in Making Software Work Together ™
(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
53
© IONA Technologies 1998-1999
The World Leader in Making Software Work Together ™