The World Leader in Making Software Work Together ™ 1 © IONA Technologies Part 2 (A) CORBA and Databases

The World Leader in Making Software Work Together ™ 2 © IONA Technologies Background info on CORBA and Databases

The World Leader in Making Software Work Together ™ 3 © IONA Technologies Some recent CORBA changes POA - portable object adapter Servant Servant Manager Default Servant

The World Leader in Making Software Work Together ™ 4 © IONA Technologies Portable Object Adapter ORB POA ORB This is the conceptual view of a server!!..... a set of CORBA 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 Servant In a POA ORB, each CORBA object is represented by two objects –a CORBA object –a servant object ORB POA CORBA objectservant

The World Leader in Making Software Work Together ™ 6 © IONA Technologies 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 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 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 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 servants Active Object Map POA

The World Leader in Making Software Work Together ™ 10 © IONA Technologies 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 Details... ORB POA Servant Manager Object fault servant

The World Leader in Making Software Work Together ™ 12 © IONA Technologies 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 Kinds of things Part 2 (B)

The World Leader in Making Software Work Together ™ 14 © IONA Technologies 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 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 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 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

The World Leader in Making Software Work Together ™ 18 © IONA Technologies 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 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 POA’s Active Object Map Recall the default way that objects are found: ORB servants Active Object Map POA Lookup

The World Leader in Making Software Work Together ™ 21 © IONA Technologies Introduce a Servant Manager... to handle object faults by activating the servant ORB servants Active Object Map POA Servant Manager (Servant Activator) Lookup fails

The World Leader in Making Software Work Together ™ 22 © IONA Technologies 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 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 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 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 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 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 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 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 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 Why integrate CORBA and Databases? Part 2 (D)

The World Leader in Making Software Work Together ™ 32 © IONA Technologies 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 1 1

The World Leader in Making Software Work Together ™ 33 © IONA Technologies 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 2 2

The World Leader in Making Software Work Together ™ 34 © IONA Technologies 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 Client Application Machines Storage Machine(s) Distributed Object DBMS

The World Leader in Making Software Work Together ™ 35 © IONA Technologies 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 Light-weight Clients using CORBA Data transfer Client Application Machines Storage Machine(s) –clients send operation invocations –all of the advantages of CORBA (bridging boundaries; interfaces; msg; standards;... ) –you are publishing interfaces, not implementations CORBA Servers -- direct access to data Operation calls

The World Leader in Making Software Work Together ™ 37 © IONA Technologies Distributed RDBMS SQL queries executed in 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 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 Storage Machine(s)

The World Leader in Making Software Work Together ™ 39 © IONA Technologies 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 Code Generation Part 2 (E)

The World Leader in Making Software Work Together ™ 41 © IONA Technologies 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 Consider the following tables What IDL would you get? BookingIDDateBookingIDSeatNum BookingDateBookingSeat

The World Leader in Making Software Work Together ™ 43 © IONA Technologies 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 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 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 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 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 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 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 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 Persistence in EJB An EJB impl can automate a lot of the work – 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 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 (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