Issue 4074: PSS storage model and associated object interactions unclear                                                                                                                                            (pss-ftf)
Source: Iconixx (Mr. Thomas S. Hawker, )
Nature: Uncategorized Issue
Severity: 
Summary: See the Persistent State Service specification, orbos/99-07-07, section
5.2.2 (or thereabouts) and section 7.
 
I am confused by the storage model "overview" given in section 5.2.2 and
the more comprehensive treatment in the discussion of the PSDL grammar
in section 7.  The treatment of abstract storage types, homes, and their
(concrete) implementations is inadequately mapped between the two,
leading to very unclear semantics.  My specific concerns:

*  It is explicitly stated in the text that types, homes, and their
   independent derivation lines are taken from a Java model.  Why this
   explicit dependence on Java?  Could the submitters not come up with a
   more generic model?  Has anyone tried to map these concepts to
   Smalltalk, which doesn't have the same kinds of object representation
   and implementation difficulties as Java and C++?  Even though I am a
   Smalltalk expert, my attempts at such a mapping on the proposed model
   have been less than exciting.
   
*  Although the keyword "abstract" was already defined, why are abstract
   storagetypes and storagehomes "abstract"?  They certainly seem
   concrete enough to me, since I would expect that the definition is
   sufficient to generate code equivalent to a valuetype.  This
   ambiguates both the general IDL concept of abstraction and concrete
   storagetypes in particular:  in all other places abstract types
   represent non-instantiable objects that have no explicit state, and
   it is not at all clear how concrete storagetypes are more "concrete"
   than their abstract relatives.
   
*  The text indicates that each storagetype must have its own home.  Is
   that abstract types, concrete types, or both?  Why?  Whatever
   happened to polymorphism?  If I have multiple storagetypes with
   similar or compatible keying properties, why cannot they all be
   indexed or managed together?  I should only require a different home
   if the behavior is different.  Even if a language mapping [read that
   as "implementation"] should require such, please don't make that a
   general limitation of the entire model.  This is a very useful
   service;  let's not restrict its utility or expressive power by
   playing to language limitations.
   
*  I can understand that you want to keep factory, finder, and
   management behavior separate from storage object behavior, but has
   anyone actually articulated the reasons behind this?  (This also
   affects the component model.)  What are they?  I can see several
   reasons for keeping the factory and finder operations with the
   storagetype, in the same way valuetypes specify factory operations. 
   I am also concerned about the apparently artificial complexity
   introduced by requiring parallel derivations of storagetypes and
   storagehomes.  Why not generate the homes automatically when needed?
*  Why are keys placed on the storagehome?  It would seem more logical
   that you define the keys (as properties) of the storagetype and then
   optionally map those to indices in a datastore, catalog, or
   storagehome.  Perhaps we should indicate that, for a particular
   storagetype, certain state members may participate in a key.  Why
   isn't at least one key identified as a primary key?  Why cannot I
   explicitly define some keys as unique leaving others as non-unique to
   form inverted indices?
*  The text indicates that a concrete storagetype "implements" one or
   more abstract storagetypes.  What does this mean?  How is this
   accomplished?  What are the navigation paradigms, especially for
   multiple storagetypes?  What interfaces are expected?  This whole
   concept is too weakly specified, and the example in section 10 is too
   simple to explain multiple type implementation.
*  What is the purpose of a catalog and its limitation of singleton
   instances of storagehomes?  I can think of reasons why I would want
   multiple instances of a particular storagehome, especially for
   configuration management in the datastores.  Can one have multiple
   catalogs, and if so, how do you select one of them, since "by name"
   might not be the best keying property?

Resolution: rejected
Revised Text: 
Actions taken:
November 21, 2000: received issue
May 13, 2002: closed issue
Discussion: 
No issue here, just a serie of questions, which should have been sent directly to the PSS FTF list.
End of Annotations:=====
omg.org
Content-Type: multipart/mixed;
boundary="openmail-part-358e7f22-00000001"
X-UIDL: ~A#e9-/"!!4R~e9`GGe9

See the Persistent State Service specification, orbos/99-07-07,
section
5.2.2 (or thereabouts) and section 7.
 
I am confused by the storage model "overview" given in section 5.2.2
and
the more comprehensive treatment in the discussion of the PSDL grammar
in section 7.  The treatment of abstract storage types, homes, and
their
(concrete) implementations is inadequately mapped between the two,
leading to very unclear semantics.  My specific concerns:

*  It is explicitly stated in the text that types, homes, and their
   independent derivation lines are taken from a Java model.  Why this
   explicit dependence on Java?  Could the submitters not come up with
   a
   more generic model?  Has anyone tried to map these concepts to
   Smalltalk, which doesn't have the same kinds of object
   representation
   and implementation difficulties as Java and C++?  Even though I am
   a
   Smalltalk expert, my attempts at such a mapping on the proposed
   model
   have been less than exciting.
   
*  Although the keyword "abstract" was already defined, why are
   abstract
   storagetypes and storagehomes "abstract"?  They certainly seem
   concrete enough to me, since I would expect that the definition is
   sufficient to generate code equivalent to a valuetype.  This
   ambiguates both the general IDL concept of abstraction and concrete
   storagetypes in particular:  in all other places abstract types
   represent non-instantiable objects that have no explicit state, and
   it is not at all clear how concrete storagetypes are more
   "concrete"
   than their abstract relatives.
   
*  The text indicates that each storagetype must have its own home.
   Is
   that abstract types, concrete types, or both?  Why?  Whatever
   happened to polymorphism?  If I have multiple storagetypes with
   similar or compatible keying properties, why cannot they all be
   indexed or managed together?  I should only require a different
   home
   if the behavior is different.  Even if a language mapping [read
   that
   as "implementation"] should require such, please don't make that a
   general limitation of the entire model.  This is a very useful
   service;  let's not restrict its utility or expressive power by
   playing to language limitations.
   
*  I can understand that you want to keep factory, finder, and
   management behavior separate from storage object behavior, but has
   anyone actually articulated the reasons behind this?  (This also
   affects the component model.)  What are they?  I can see several
   reasons for keeping the factory and finder operations with the
   storagetype, in the same way valuetypes specify factory
   operations. 
   I am also concerned about the apparently artificial complexity
   introduced by requiring parallel derivations of storagetypes and
   storagehomes.  Why not generate the homes automatically when
   needed?
*  Why are keys placed on the storagehome?  It would seem more logical
   that you define the keys (as properties) of the storagetype and
   then
   optionally map those to indices in a datastore, catalog, or
   storagehome.  Perhaps we should indicate that, for a particular
   storagetype, certain state members may participate in a key.  Why
   isn't at least one key identified as a primary key?  Why cannot I
   explicitly define some keys as unique leaving others as non-unique
   to
   form inverted indices?
*  The text indicates that a concrete storagetype "implements" one or
   more abstract storagetypes.  What does this mean?  How is this
   accomplished?  What are the navigation paradigms, especially for
   multiple storagetypes?  What interfaces are expected?  This whole
   concept is too weakly specified, and the example in section 10 is
   too
   simple to explain multiple type implementation.
*  What is the purpose of a catalog and its limitation of singleton
   instances of storagehomes?  I can think of reasons why I would want
   multiple instances of a particular storagehome, especially for
   configuration management in the datastores.  Can one have multiple
   catalogs, and if so, how do you select one of them, since "by name"
   might not be the best keying property?

Tom Hawker, Iconixx
thawker@iconixx.com