210 likes | 308 Views
An Introduction Jamie Shiers, IT/ASD, CERN Reviewer Member, ODMG. Introduction. What is the ODMG? What are its goals? Why it is relevant to HEP. The ODMG. The Object Database Management Group is
E N D
An Introduction Jamie Shiers, IT/ASD, CERN Reviewer Member, ODMG
Introduction • What is the ODMG? • What are its goals? • Why it is relevant to HEP
The ODMG The Object Database Management Group is • a consortium of object-oriented database management system (ODBMS) vendors and interested parties working on standards to allow portability of customer software across ODBMS products Mission Statement • The mission of the Object Database Management Group consists of four key objectives. • EVOLVE: Continue to develop the standard • PROMOTE: Raise awareness of ODMG 2.0 • EDUCATE: Explain ODMG 2.0 features and benefits • VALIDATE: Assure compliance to ODMG 2.0
ODMG Members Voting Members • must ship, or have announced intent to ship, a compliant ODBMS • Gemstone • IBEX (Itasca) • Lockheed Martin (ADA-95 binding) • Objectivity • ODI (ObjectStore) • POET • Versant • Vmark (UniData/O2) Reviewer Members include CERN and others
ODMG Standard • Provides the only standard for object databases • Implemented by numerous vendors • Includes language bindings: • C++, Java, Smalltalk, [ ADA-95 ] • Includes Object Interchange Format (OIF) • The Object Interchange Format (OIF) is a specification language used to dump and load the current state of an object database to or from a file or set of files. OIF can be used to exchange objects between databases, seed databases, provide database documentation and drive database test suites.
ODMG and Other Standards • Java, C++ and Smalltalk language bindings build on corresponding language standard • OQL provides object query capability and is 90% compatible with SQL-92 SELECT • OQL is an OMG Data Query service • ODMG is an OMG PDS (Persistent Data Service) protocol • ODL is a superset of the OMG IDL • ODMG is a superset of the OMG Common Object Model
Future Enhancements • To bring the OQL object model to the centre of the SQL3 standard • To enhance object programming language bindings, including the addition of a Java language binding • available as from ODMG 2.0 • To define an OMG CORBA Object Manager Adapter interface for object databases • To achieve greater interoperability between ODMG compliant databases beyond schema level (ODL). • To provide dynamic access to meta-objects (schema)
Object Definition Language ODL (Object Definition Language): • The ODMG ODL is a database schema definition language extension of the OMG Interface Definition Language (IDL). Because it is restricted to object type definitions without regard to the actual implementation of the methods behind them, ODL makes it possible to describe a database schema independent of the programming language thereby making the schema portable between compliant databases.
Object Query Language OQL (Object Query Language): • OQL is an SQL-like declarative language that provides a rich environment for efficient querying of database objects, including high-level primitives for object sets and structures, while retaining compatibility with the SQL-92 SELECT syntax.
Language Bindings • ODMG’s Java, C++ and Smalltalk bindings define OMLs (Object Manipulation Languages) that extend the ANSI standards to support manipulation of persistent objects, OQL, navigation and transactions. Because each language has its own OML, developers can work in a single language environment without separate programming and database languages. • “The programmer should perceive the binding as a single language for expressing both programming and database operations, not two languages with arbitrary boundaries between them.”
Init(); // initialise the db session startUpdate(); // start an update transaction // create a new database (file) HepDatabaseRef myDb = db("MyDatabase"); // create a new container in this database HepContainerRef cont = container("MyContainer"); if (cont == 0 ) fatal("could not find or create MyDatabase"); for (short i=0; i<1000; i++) { // create a new event in my container HepRef(HepEvent) event = new(cont) HepEvent; if (event == 0) fatal("could not create a new event"); } EXEC SQL WHENEVER SQLWARNING GOTO 1100 EXEC SQL LOCK TABLE FATMEN IN SHARE MODE EXEC SQL SELECT * INTO :DBASE, :EXPER FROM FATMEN 2 WHERE DATABASE =:DBASE AND EXPERIMENT =:EXPER STMT1 = 'LOCK TABLE GNAMES_' // EXPER(1:LEXP) // ', FILES_' // 1 EXPER(1:LEXP) // ', FXV_' // EXPER(1:LEXP) // 2 ',VOLUMES_' // EXPER(1:LEXP) // ' IN EXCLUSIVE MODE' CMD = 'STMT1' EXEC SQL EXECUTE IMMEDIATE :STMT1 ODMG vs Embedded SQL
HepODBMS Primary goals are: • Minimise the dependence on given ODBMS implementation (vendor or release), • Provide a higher-level interface to ODBMS, • Minimise the effort involved in porting existing applications that require persistence. Examples of additional functionality: • Event collection classes (109 - 1011 events), • Enhanced clustering, • Naming, HEP Meta-Data, • Calibration Database Application, ...
ODMG non-goals • We do not wish to produce identical ODBMS products. Our goal is source code portability; there is a lot of room for future innovation in a number of areas. There will be differences between products in performance, languages supported, functionality unique to particular market segments (e.g., version and configuration management), accompanying programming environments, application construction tools, small versus large scale, multithreading, networking, platform availability, depth of functionality, suites of predefined type libraries, GUI builders, design tools, and so on.
ODMG & RD45 • Many of RD45’s milestones have been directly related to the ODMG: 1995: • An evaluation of the suitability of ODMG's Object Definition Language for specifying an object model describing HEP event data. • Starting from such a model, the development of a prototype using commercial ODBMSs that conform to the ODMG standard. The functionality and performance of the ODBMSs should be evaluated. 1996: • Identify and analyse the impact of using an [ ODMG-compliant ] ODBMS for event data on the Object Model, the physical organisation of the data, coding guidelines and the use of third party class libraries. • These issues have been reported on to the LC(R)B and other committees
Need for a Standard Interface A paper at HepVIS ’95 & the CMS CTP both stress: • Correctness, • Homogeneity, • Consistency, • Fault tolerance, • Ease of use. In today’s (CERNLIB) environment, many different interfaces for different types of data • (FZ,RZ,HBOOK,HEPDB,FATMEN, etc.) One of the first discussions in RD45 revealed importance of a consistent interface • Two potential candidates: ODMG & OMG POS
RD45: First Steps • Evaluations of existing packages/prototypes/solutions • Discussions with experts in the field • Presentations by vendors • O2, ODI (ObjectStore), Objectivity, Iona (Orbix) • Training • O2, Objectivity • Mentoring • Doug Barry, Rick Cattell, Sean Baker, Sophie Gamerman, Leon Guzenda • Close contacts with other ‘similar’ projects • Strong support for ODMG • including from Iona, who declared OMG POS as “unimplementable” • POS has since been withdrawn and a new version, compatible with ODMG, is being discussed
OMG Persistent State Service • PSS2 is a new OMG service. The intent was a second generation (replacement) to the old POS (persistent object service), that has seen very little use… • PSS2 is based on a single-level approach, … simpler, better (up to date with ODMG interfaces), and better integrated with ORB products. • The idea is to take the experience ... like that with Orbix, and generalize it to a standard… • [ ODMG is still the only implemented standard in the persistent-object space ]
Benefits of ODMG Membership • Possibility to influence ODMG standards are somewhat limited • would require significant extra participation, e.g. 1 week/month in the US, to change this • Benefits in learning of ODMG’s direction long before standards are published • as book “The Object Database Standard, Morgan Kaufmann” • helps influence vendor to move to ODMG compliance in a timely manner • Exposure to architectural details of different products • Chance to meet developers • Current participation ~1 meeting/year
Summary • The ODMG language bindings are successful in their goal of being a “natural extension” to the programming language • ODL (Objectivity/DB DDL) has been shown to be suitable for describing HEP object models • ODMG-compatible ODBMS products meet HEP’s requirements in terms of providing a consistent interface to all types of data • histograms, calibration data, event data etc.