Part 2 (A) CORBA and Databases

1. Part 2 (A) CORBA and Databases

2. Background info on CORBA and Databases

3. Some recent CORBA changes • POA - portable object adapter • Servant • Servant Manager • Default Servant

4. Portable Object Adapter 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) POA ORB ORB

5. Servant • In a POA ORB, each CORBA object is represented by two objects • a CORBA object • a servant object CORBA object servant POA ORB

6. 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.]

7. 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.

8. Details - class hiararchy Interface FrontOffice { ..... }; servant ServantBase IDL CORBA object C++ CORBA::Object POA_FrontOffice FrontOffice FrontOffice_i

9. 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

10. POA ORB Servant Activation • Servants can be deactivated and activated without effecting their accessibility by clients servant

11. Servant Manager POA ORB Details... servant Object fault

12. 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

13. Kinds of things Part 2 (B)

14. Kinds of CORBA objects Don’t put them in the Naming Service • 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.

15. 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

16. 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

17. Types of Database Integration 1 • 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 2 3

18. ... Loading (cont) Statically load the FrontOffice object interface FrontOffice { 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 (....); }; FrontOffice - statically load. Booking - Load objects when they are invoked upon. interface Booking {.....}; interface FrontOffice { Booking makeBooking (....); };

19. 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

20. servants Active Object Map POA ORB POA’s Active Object Map • Recall the default way that objects are found: Lookup

21. Introduce a Servant Manager • ... to handle object faults by activating the servant servants Active Object Map Servant Manager (Servant Activator) Lookup fails Lookup POA ORB

22. ... But the Active Object Map may be inappropriate • Select a policy that removes it: servants Servant Manager (Servant Activator) 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. POA ORB

23. 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.

24. 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

25. 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.

26. 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

27. 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)

28. 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

29. 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)

30. 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.

31. Why integrate CORBA and Databases? Part 2 (D)

32. 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

33. From the Database viewpoint 2 • 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

34. 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)

35. Issues Q • 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

36. 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

37. 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.

38. 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 !

39. 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.

40. Code Generation Part 2 (E)

41. 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

42. Consider the following tables BookingDate BookingSeat • What IDL would you get? BookingID Date BookingID SeatNum

43. 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” };

44. 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.

45. 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...

46. 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.

47. 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 ...

48. 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.

49. 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, ...

50. 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 Tables