Date post: | 27-Dec-2015 |
Category: |
Documents |
Upload: | mervin-flynn |
View: | 215 times |
Download: | 0 times |
The World Leader in Making Software Work Together ™1 © IONA Technologies 1998-1999
Part 2 (A)
CORBA and Databases
The World Leader in Making Software Work Together ™2 © IONA Technologies 1998-1999
Background info on CORBA and Databases
The World Leader in Making Software Work Together ™3 © IONA Technologies 1998-1999
Some recent CORBA changes
• POA - portable object adapter
• Servant
• Servant Manager
• Default Servant
The World Leader in Making Software Work Together ™4 © IONA Technologies 1998-1999
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)
The World Leader in Making Software Work Together ™5 © IONA Technologies 1998-1999
Servant
• In a POA ORB, each CORBA object is represented by two objects
– a CORBA object
– a servant object
ORB
POA
CORBA object servant
The World Leader in Making Software Work Together ™6 © IONA Technologies 1998-1999
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.]
The World Leader in Making Software Work Together ™7 © IONA Technologies 1998-1999
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.
The World Leader in Making Software Work Together ™8 © IONA Technologies 1998-1999
Details - class hiararchy
CORBA::Object
FrontOffice
Interface FrontOffice {.....};
ServantBase
POA_FrontOffice
FrontOffice_i
IDL
C++
CORBA object
servant
The World Leader in Making Software Work Together ™9 © IONA Technologies 1998-1999
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
The World Leader in Making Software Work Together ™10 © IONA Technologies 1998-1999
ORB
POA
Servant Activation
• Servants can be deactivated and activated without effecting their accessibility by clients
servant
The World Leader in Making Software Work Together ™11 © IONA Technologies 1998-1999
Details...
ORB
POA
Servant Manager
Objectfault
servant
The World Leader in Making Software Work Together ™12 © IONA Technologies 1998-1999
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
The World Leader in Making Software Work Together ™13 © IONA Technologies 1998-1999
Kinds of things
Part 2 (B)
The World Leader in Making Software Work Together ™14 © IONA Technologies 1998-1999
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
The World Leader in Making Software Work Together ™15 © IONA Technologies 1998-1999
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
The World Leader in Making Software Work Together ™16 © IONA Technologies 1998-1999
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
The World Leader in Making Software Work Together ™17 © IONA Technologies 1998-1999
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
The World Leader in Making Software Work Together ™18 © IONA Technologies 1998-1999
... 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.
The World Leader in Making Software Work Together ™19 © IONA Technologies 1998-1999
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
The World Leader in Making Software Work Together ™20 © IONA Technologies 1998-1999
POA’s Active Object Map
• Recall the default way that objects are found:
ORB
servants
ActiveObjectMap
POA
Loo
kup
The World Leader in Making Software Work Together ™21 © IONA Technologies 1998-1999
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
The World Leader in Making Software Work Together ™22 © IONA Technologies 1998-1999
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:
The World Leader in Making Software Work Together ™23 © IONA Technologies 1998-1999
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.
The World Leader in Making Software Work Together ™24 © IONA Technologies 1998-1999
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
The World Leader in Making Software Work Together ™25 © IONA Technologies 1998-1999
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).
The World Leader in Making Software Work Together ™26 © IONA Technologies 1998-1999
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
The World Leader in Making Software Work Together ™27 © IONA Technologies 1998-1999
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)
The World Leader in Making Software Work Together ™28 © IONA Technologies 1998-1999
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
The World Leader in Making Software Work Together ™29 © IONA Technologies 1998-1999
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)
The World Leader in Making Software Work Together ™30 © IONA Technologies 1998-1999
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.
The World Leader in Making Software Work Together ™31 © IONA Technologies 1998-1999
Why integrate CORBA and Databases?
Part 2 (D)
The World Leader in Making Software Work Together ™32 © IONA Technologies 1998-1999
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
The World Leader in Making Software Work Together ™33 © IONA Technologies 1998-1999
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
The World Leader in Making Software Work Together ™34 © IONA Technologies 1998-1999
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
The World Leader in Making Software Work Together ™35 © IONA Technologies 1998-1999
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
The World Leader in Making Software Work Together ™36 © IONA Technologies 1998-1999
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
The World Leader in Making Software Work Together ™37 © IONA Technologies 1998-1999
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
The World Leader in Making Software Work Together ™38 © IONA Technologies 1998-1999
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)
The World Leader in Making Software Work Together ™39 © IONA Technologies 1998-1999
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.
The World Leader in Making Software Work Together ™40 © IONA Technologies 1998-1999
Code Generation
Part 2 (E)
The World Leader in Making Software Work Together ™41 © IONA Technologies 1998-1999
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
The World Leader in Making Software Work Together ™42 © IONA Technologies 1998-1999
Consider the following tables
• What IDL would you get?
BookingID Date BookingID SeatNum
BookingDate BookingSeat
The World Leader in Making Software Work Together ™43 © IONA Technologies 1998-1999
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”
};
The World Leader in Making Software Work Together ™44 © IONA Technologies 1998-1999
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.
The World Leader in Making Software Work Together ™45 © IONA Technologies 1998-1999
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...
The World Leader in Making Software Work Together ™46 © IONA Technologies 1998-1999
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.
The World Leader in Making Software Work Together ™47 © IONA Technologies 1998-1999
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 ...
The World Leader in Making Software Work Together ™48 © IONA Technologies 1998-1999
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.
The World Leader in Making Software Work Together ™49 © IONA Technologies 1998-1999
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, ...
The World Leader in Making Software Work Together ™50 © IONA Technologies 1998-1999
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
The World Leader in Making Software Work Together ™51 © IONA Technologies 1998-1999
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
The World Leader in Making Software Work Together ™52 © IONA Technologies 1998-1999
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
The World Leader in Making Software Work Together ™53 © IONA Technologies 1998-1999
(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