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

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

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

4. The World Leader in Making Software Work Together ™ 4 © IONA Technologies 1998-1999 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)

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

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

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

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

9. 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 servants Active Object Map POA

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

11. The World Leader in Making Software Work Together ™ 11 © IONA Technologies 1998-1999 Details... ORB POA Servant Manager Object fault servant

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

13. The World Leader in Making Software Work Together ™ 13 © IONA Technologies 1998-1999 Kinds of things Part 2 (B)

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

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

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

17. 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 1 1 2 2 3 3

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

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

20. 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 Active Object Map POA Lookup

21. 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 Active Object Map POA Servant Manager (Servant Activator) Lookup fails

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

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

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

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

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

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

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

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

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

31. The World Leader in Making Software Work Together ™ 31 © IONA Technologies 1998-1999 Why integrate CORBA and Databases? Part 2 (D)

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

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

34. 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 Client Application Machines Storage Machine(s) Distributed Object DBMS

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

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

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

38. 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 Storage Machine(s)

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

40. The World Leader in Making Software Work Together ™ 40 © IONA Technologies 1998-1999 Code Generation Part 2 (E)

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

42. The World Leader in Making Software Work Together ™ 42 © IONA Technologies 1998-1999 Consider the following tables What IDL would you get? BookingIDDateBookingIDSeatNum BookingDateBookingSeat

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

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

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

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

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

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

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

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

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

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

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