Object-Oriented Data Bases [OODBs] Data Model [OODM] Prog. Langs [OOPLs]

1. Object-Oriented Data Bases [OODBs] Data Model [OODM] Prog. Langs [OOPLs] Non-OO data models believed inadequate for eg - CAD/CAM, CIM - Image, Graphics, Multimedia DBs - uniform access to multiple DBs CAD/CAM, CIM, Multimedia applications often characterised by • more complex structures • transactions of longer duration • awkward new data types (images, large texts, audio, video, trees, …) • need for nonstandard application-specific operations, eg image matching http://csiweb.ucd.ie/staff/acater/comp30150.html

2. OODMs (OO Data Models) give a designer power to specify - structure of objects - operations on objects Object Classes encapsulate behaviour: • implementation details are hidden • operations are manifest (just like Abstract Data Types) http://csiweb.ucd.ie/staff/acater/comp30150.html

3. OOPLs have inheritance and message passing. • Pure OOPLs, eg SMALLTALK, have explicit OO design; • Hybrid OOPLs, eg C++, augment HLL with OO features. OOPLs allow programs to create and manipulate transient objects. OODBs interface with one or more OOPL • to provide persistent objects • to allow sharing among programs and applications They need to offer DB features such as recovery, concurrency, security. http://csiweb.ucd.ie/staff/acater/comp30150.html

4. Object identifiers (cf keys, RM/T surrogates) provide for • Correspondence between real-world objects and DB objects • The sameness of an entity described in different ways needs to be established somehow: • eg student exam number for written examinations in UCD needs to be tied to name+class+year for continuous assessment work • Possibly, repeated access by program to the same object in multiple sessions • Links between complex objects and their component parts, etc. Object structure may be arbitrarily complex, cf. scattering information across several relations. http://csiweb.ucd.ie/staff/acater/comp30150.html

5. Instance variables roughly resemble relational attributes - but perhaps encapsulated in methods and so not directly visible - may hold arbitrarily complex structures, not just atomic values Relationships between objects are representable (1) by methods that locate related objects - strict, ideological encapsulation (2) citing object identifiers of related objects within self - clearly identifies relationship. Especially valuable in complex databases with multiple relationships, makes related objects visible to users. http://csiweb.ucd.ie/staff/acater/comp30150.html

6. Designer (of suite of application programs sharing data) can define operations on a class. (Must there be an operation defined for every simple kind of retrieval?) Op. signature (interface) - name & argument types Op. method (body) - the implementation Op. invocation by passing message to object, giving op name and arguments. This encapsulation allows changing object structure and method implementation without disturbing external programs - a kind of Logical Data Independence. http://csiweb.ucd.ie/staff/acater/comp30150.html

7. Class hierarchies allow method inheritance. Operator overloading / polymorphism is commonplace - methods may be specialised on object classes. OODB may • have capabilities for dealing with multiple versions of the same object • useful in design, engineering (and software engineering) applications • support schema evolution • changing data types • adding new types • adding new relationships http://csiweb.ucd.ie/staff/acater/comp30150.html

8. OODB provides unique, immutable object identifiers [OIDs]. • Strict Ideology - everything has an OID • Common Practice - scalar values stand for themselves States of objects can be built by type constructors: • atom, tuple, set commonly • list, array, bag less commonly An OO DDL defines classes as a combination of • (nested) constructor expressions • operations http://csiweb.ucd.ie/staff/acater/comp30150.html

9. http://csiweb.ucd.ie/staff/acater/comp30150.html

10. Objects are made persistent by one of two methods: • giving them a unique persistent name, in the schema, or • making them reachable from another object which is (or will be made) persistent • using operations like “add to list” • This implies a need for Garbage Collection of persistent object store (Elmasri & Navathe do not mention this) Programs may make transient copies of persistent objects; and may create objects and cause them to become persistent - by linking them to another persistent object, maybe a named one. http://csiweb.ucd.ie/staff/acater/comp30150.html

11. OODBMS may need to store and retrieve large unstructured complex objects, such as • image bitmaps • sound recordings • long text strings Such things are often treated as "Binary Large Objects" - BLOBs http://csiweb.ucd.ie/staff/acater/comp30150.html

12. DBMS does not know about any structure within BLOBs; • only an application can interpret their meaning • DBMS alone cannot be expected to selectively retrieve them on the basis of their content • DBMS can retrieve them only when given the object id • BLOBs are not of standard DBMS types • BLOBs often require considerable storage • being large, DBMS and application may conspire to transmit/supply part of object before all is retrieved http://csiweb.ucd.ie/staff/acater/comp30150.html

13. CORBA Common Object Request Broker Architecture OMG - “Object Management Group” OMG, a group of about 500 organisations (see www.omg.org) promotes standards for inter-operation of object-oriented systems, across boundaries of • Operating Systems, • Networks, • Programming languages. http://csiweb.ucd.ie/staff/acater/comp30150.html

14. RPC - Remote Procedure Call RMI - Remote Method Invocation ORB - Object Request Broker OQL - Object Query Language ODMG - Object Data Management Group ODMG-93 = -1.0; ODMG-2.0 standards OMA - Object Management Architecture ODL - Object Definition Language IDL - Interface Definition Language GIOP - General Inter- ORB Protocol IIOP - Internet Inter- ORB Protocol DII - Dynamic Invocation Interface DSI - Dynamic Skeleton Interface BOA - Basic Object Adapter http://csiweb.ucd.ie/staff/acater/comp30150.html

15. RMI is an OO extension of RPC, that provides a generic communication mechanism allowing objects on different computers to interact transparently. • Client objects use server object stubs; • Server objects and their stubs each depend on local RMI runtime support for the underlying message passing. http://csiweb.ucd.ie/staff/acater/comp30150.html

16. RMI is an OO extension of RPC, that provides a generic communication mechanism allowing objects on different computers to interact transparently. • Client objects use server object stubs; • Server objects and their stubs each depend on local RMI runtime support for the underlying message passing. http://csiweb.ucd.ie/staff/acater/comp30150.html

17. Manually creating stubs is pointless, direct message-passing is just as easily programmed. But automated stub generation, from object interface definitions, does simplify programming. It can be done • by extending an existing HLL, or • by using a platform-independent language-independent IDL, with compilers producing stubs for all languages and all platforms. OMG promotes CORBA, which defines • a particular IDL, • ORB - the RMI runtime support, • Inter-ORB communication protocols. http://csiweb.ucd.ie/staff/acater/comp30150.html

18. An ORB is basically a process running on a computer, which provides services to other processes on the same machine and to other ORBs on different machines. The CORBA IDL has elements • Operations: essentially method declarations. • Their parameters have {in, out, inout} modes, • An operation may or may not be "oneway", - returning no result, having no out or inout parameters • Exceptions • Standardised data types • basic types (long, float, char etc) • constructed types (string, array, seq etc) • Attributes (may be read-only) • Modules (for namespaces) http://csiweb.ucd.ie/staff/acater/comp30150.html

19. An IDL compiler generates, for a particular HLL-OS-Platform combination: • a header file, for use by implementations of client & server objects • a stub, for use by client object • an object-definition skeleton, needing to be turned into an object implementation by further programmer effort. Stubs provide static methods that can be invoked by a client object, these methods will communicate transparently with the local ORB. That local ORB will if necessary find a remote server ORB (possible because objects "register" their identity and their interface with an ORB, using its Interface Repository). The server ORB invokes the methods of the server object, and provides other services to it (eg registering, timeouts) via an "object adapter". http://csiweb.ucd.ie/staff/acater/comp30150.html

20. CORBA demands that ORBs implement a standard BOA; an OO Database Adapter standard is also proposed. Interface Repository API provides DII (Dynamic Invocation Interface) ability - with which a client object may dynamically discover objects & their methods, and invoke those methods, using metadata. Server ORB uses DSI (Dynamic Skeleton Interface) ability for dynamic objects with no static skeleton. http://csiweb.ucd.ie/staff/acater/comp30150.html

21. The OMA (Object Management Architecture) is a collection of standard but optional object interfaces, built on top of a CORBA core, providing • CORBAservices - system-level services for standardising the lifecycle of objects: such as object naming, object creation, object relocation, controlling access to objects • CORBAfacilities - higher-level services - categorised as • "horizontal" generic facilities useful across many domains - eg printing • "vertical" facilities useful in one particular application domain, eg telecom. Some CORBAservices - eg concurrency control, query services - overlap with desired features of a DBMS. http://csiweb.ucd.ie/staff/acater/comp30150.html

22. "The OMG has not yet standardised the use of a ODBMS within CORBA. The ODMG has addressed this issue in a position statement, indicating that the integration of an ODBMS in an OMA ORB must respect the goals of distribution and heterogeneity while allowing the ODBMS to be responsible for its multiple objects. The relationship between the ORB and the ODBMS should be reciprocal; the ORB should be able to use the ODBMS as a repository and the ODBMS should be able to use the services provided by the ORB." There would be prohibitive overhead if each ODBMS object were individually registered with ORB, hence the desirability of a specialised alternative to BOA, the Object Database Adapter, for flexibility and performance. ORB may handle access to unregistered objects maintained within ODBMS by invoking methods of the ODBMS. http://csiweb.ucd.ie/staff/acater/comp30150.html