Summary by Arie Shoshani.
This working group settled on this architectural view (derived from Bill Johnston).
|
| Also in .ps and .pdf. |
From malon@sun3.hep.anl.gov Fri Jul 11 11:06:19 1997
The principal role of the object presenter is to mediate an application's access to data so that such data appear in an appropriate object form. What an appropriate form is might depend upon the application; for this reason, multiple object presenters are depicted in the strawman architectural diagram. The commercial database package Objectivity is an example of a potential object presenter, although Objectivity's functionality overlaps many other architectural components as well.
The plan described in the Grand Challenge proposal is that objects should be presented in an ODMG-compliant form, at least to C++ programs. This means, among other things, that the architecture should support navigational access from any persistent object to any other persistent object by means of a "smart pointer" reference class (d_Ref<T> in ODMG), even if the target object has not been prefetched or otherwise been made available locally. (Such access should be efficient and natural for locally cached objects, but the system need not be tuned for this sort of one-at-a-time access to completely arbitrary objects.)
Because Objectivity is not, at present, ODMG-compliant, there are a number of issues that must be addressed if Objectivity is to be a candidate for inclusion as an object presenter in this architecture. One possibility is to provide an ODMG-compliant interface layer above Objectivity. This may be difficult to accomplish cleanly because of Objectivity's partial, customized implementations of parts of the ODMG specification. Here the work of CERN's RD45 project is germane, although not directly a solution to this problem--the project has developed an interface layer, though not specifically or exclusively for this purpose. This software is not quite ODMG-compliant, and does not reflect Objectivity's most recent work in the direction of compliance; further, it has raised performance and functionality questions in the context of BaBar trials.
Software developed at Argonne National Laboratory implements a substantial subset of the ODMG C++ binding, but it does not offer the full functionality of a database. Because of its ODMG-aware implementation and its source code availability for tailoring to the needs of the Grand Challenge, this software may be a candidate for use in early prototypes of the strawman architecture.
In the STAR collaboration (and, to some extent, in PHENIX as well), it is important that the object presenter be compatible with the STAR Analysis framework (STAF). STAF cannot, at present, deliver ODMG-compliant objects; moreover, there are analysis codes (written in FORTRAN, for example) that would be unable to deal with such objects even if STAF could deliver them. This is one of the reasons for multiple object presenters in the strawman architecture; nonetheless, it is important in the coming months that the collaboration define compatible modes of interaction between STAF and an ODMG- and/or Objectivity-compliant object representation. A number of models should be explored, including evolution of STAF to deliver objects, and marshalling/unmarshalling objects out of and/or into STAF tables and datasets. Because ODMG's Object Data Language (ODL) is a superset of OMG's Interface Definition Language (IDL), the possibility of an approach to STAF/presenter interaction that allows STAF to deliver ODMG objects while maintaining its CORBA compliance is an open issue.
There are many open questions concerning the interface between the object presenter and the data as delivered by the storage manager (via the data mover). For Objectivity and for the Argonne ODMG-aware software, it would be natural to work with data delivered in pages, because of the way in which smart pointers are managed. Some of the currently articulated views of "complex query path" implementations suggest, on the other hand, that delivering objects, or sequences or streams of objects, would be a more natural fit. The latter approach would map more directly into the current STAF architecture as well. These and related problems are important areas for research in the construction of any initial prototype.
Objectivity may pose additional interface issues on the storage end. While Objectivity provides much of the functionality of an object presenter as envisioned in this model, it provides many other services as well. An implementation that uses Objectivity in an object presenter role and hopes to connect Objectivity's data access requests to externally provided storage management services may require that additional features (e.g., hooks or the ability to intercept internal Objectivity requests) be provided by the vendor. These are questions that can best be addressed in the context of defining early prototype implementations.
Back to 30 June, 1 July 1997 meeting page.
Last modified: 21 July 1997