gnue/geas/doc odmg.txt

[Daniel E. Baumann]

CVSROOT:        /cvsroot/gnue
Module name:    gnue
Changes by:     Daniel E. Baumann <address@hidden>      02/03/02 06:41:35

Modified files:
        geas/doc       : odmg.txt 

Log message:
        Add operation notes, exception model, and started metadata notes.

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gnue/gnue/geas/doc/odmg.txt.diff?tr1=1.9&tr2=1.10&r1=text&r2=text

Patches:
Index: gnue/geas/doc/odmg.txt
diff -c gnue/geas/doc/odmg.txt:1.9 gnue/geas/doc/odmg.txt:1.10
*** gnue/geas/doc/odmg.txt:1.9  Tue Feb 26 00:24:49 2002
--- gnue/geas/doc/odmg.txt      Sat Mar  2 06:41:35 2002
***************
*** 1329,1331 ****
--- 1329,1441 ----
           void drop_teaches(in Course a Course) raises(IntegrityError);
           void add_teaches(in Course aCourse) raises(IntegrityError);
           void remove_teaches(in Course aCourse) raises(IntegrityError);
+ 
+   Modeling Behavior--Operations
+   =============================
+   - behavior specified as a set of operation signatures
+   - each signature defines the name of the operation, the name and
+   type of each of its arguments, the types of value(s) it
+   returned, and the names of any exceptions (error conditions) the
+   operation can raise
+   - ODMG Object Model specification for operations is identical to OMG
+   CORBA specifications for operations (in IDL)
+   - No notions of operations that exist independently of a type
+   in the Object Model
+   - operation name only need be unique within a single type
+   definition, thus different types can have operations with the same
+   name, these are called overloaded operations
+   - when an operations is invoked using an overloaded name, a specific
+   operations must be selected for execution
+   - this selection, sometimes called operation name resolution or
+   operations dispatching, is based on the most specific type of the
+   object supplied as the first argument of the actual call
+   
+     Exception Model
+     ===============
+     - ODMG Object Model supports dynamically nested exception
+     handlers, using a termination model of exception handling
+     - operations can raise exceptions, and exceptions can communicate
+     exception results
+     - when an exception is raised, information on the cause of the
+     exception is passed back to the exception handler as properties of
+     the exception, control is as follows:
+ 
+       1. The programmer declares an exception handler within scope 's'
+          capable of handling exceptions of type 't'
+       2. An operation within a contained scope 's'' may "raise" an
+          exception of type 't'
+       3. The exception is "caught" by the most immediately containing
+          scope that has an exception handler. the call stack is
+          automatically unwound by the runtime system out to the level
+          of the handler. memory is freed for all objects allocated in
+          intervening stack frames, any transactions begun within a
+          nested scope, that is, for an exception handler, are
+          aborted.
+       4. when control reaches the handler, the handler may either
+          decide that it can handle the exception or pass it on
+          (re-raise it) to a containing handler
+ 
+     - exception handler that declares itself capable of handling
+       exceptions of type 't' will also be able to handle exceptions of
+       any subtype 't', programmer who requires more specific control
+       over exceptions of a specific subtype 't' may declare a handler
+       for this more specific subtype within a contained scope
+ 
+   Metadata
+   ========
+   - metadata is descriptive information about persistent objects that
+   defines the 'schema' of an ODMS
+   - metadata is used by ODMS to define structure of its object
+   storage, and at runtime, guide access to ODMS's persistent objects
+   - metadata is stored in an 'ODL Schema Repository', which is also
+   accessible to tools and applications using the same operations that
+   apply to user-defined types
+   - in OMG CORBA environments, similar metadata is stored in an IDL
+   repository
+ 
+   - following interfaces define the internal structure of an ODL
+     Schema Repository, these interfaces are defined in ODL using
+     'relationships' that define the graph of interconnections between
+     'meta objects', which are produced, for example, during ODL source
+     compilation
+   - while these relationships guarantee referential integrity of th
+     meta object graph, the y do not guarantee its semantic integrity
+     or completeness
+   - in order to provide operations that programmers can use to
+     correctly construct valid schemas, several creation, addition, and
+     removal operations are defined that provide automatic linking and
+     unlinking of the required relationships and appropriate error
+     recovery in the even of semantic errors
+   - all meta object definitions defined below are in the following
+     module:
+ 
+       module ODLMetaObjects
+       {
+         // the following interfaces are defined here
+ 
+       };
+  
+     Scopes
+     ======
+     - scopes define naming hierarchy for the meta objects in the
+     repository
+     
+       interface Scope
+       {
+         exception  DuplicateName{};
+       
+         exception  NameNotFound{string reason; };
+ 
+         // Adds meta objects to the repository
+         void       bind(in string name, in MetaObject value)
+                        raises(DuplicateName);
+ 
+         // Resolves path names within the repository
+         MetaObject resolve(in string name) raises(NameNotFound);
+  
+         // Removes bindings form the repository
+         void       unbind(in string name) raises(NameNotFound);
+ 
+         list<RepositoryObject> children();
+ 
+       };
\ No newline at end of file