Persistence for Ada-9X?

Persistence for Ada-9X?

[Oliver Kellogg]

Is anyone developing persistent object support for Ada 9X?
If not, who'd be interested joining me doing it (as GPLed freeware) ?

/-- Oliver M. Kellogg | mail: okellogg@cube.net | Fax: (+49)89-60723732 --\
\-- Dept. RST13, Deutsche Aerospace AG, P.O. Box 801169, D-81663 Munich --/

Re: Persistence for Ada-9X?

[R. William Beckwith]

Oliver Kellogg (okellogg@cube.net) wrote:
: Is anyone developing persistent object support for Ada 9X?

    We are, sort of.  Persistence is made easier with CORBA
    and we're working on a CORBA product.  I'll explain below.

: If not, who'd be interested joining me doing it (as GPLed freeware) ?

My view of persistance involves (at least) these four elements:

    1.	represent arbitrarily complex types into byte streams

    2.  determine the link separation scheme and support the
	resulting paradymn  (in simpler terms: determine if
	objects that point to other objects must all go together
	or if they are allowed to be separately stored to and
	retrieved from disk)

    3.	provide an access mechanism in an extensible fashion to
	store the objects to and retrieve the objects from various
	forms (ISAM, flat files, Direct_IO, SQL DBMS, etc.)

    4.	determine and implement the paradymn for sharing objects
	by different processes (locking, transaction control, and
	security)

CORBA allows the authors of a server to implement persistance.
CORBA and Ada 9X help each of the above as follows:

    1.	Ada 9X's 'READ and 'WRITE do this nicely.

    2.	CORBA helps by not forcing you into a particular link
	separation scheme via CORBA's portable, persistant
	object references.  This allows you to write an object
	with its pointers to disk without writing all of the 
	the `pointed to' objects to disk.

    3.	Ada 9X's stream interfaces are nicely suited to this task.
	In addition, you may want to inherit an object
	create_from_store type of function for construction.

    4.	In traditional persistance mechanisms you create
	multiple object instances in separate processes from
	the same data and then worry about coordination.
	CORBA simplifies the sharing issue because only one
	object instance is created and the other processes
	have remote references to that one object.

It seems to me that if you pick an all or nothing strategy for (2)
and you assert that only one process will use the same persistance
data (4), then it should be fairly easy to set up (1) and (3).

Hope this helps a little.  Sounds like a fun project.

... Bill

-- 
e-mail: Bill.Beckwith@ois.com       |    Team Ada
Objective Interface Systems, Inc.   | dist, full O-O
1895 Preston White Drive, Suite 250 | multithreading
Reston, VA  22091-5448  U.S.A.      |    built in

Re: Persistence for Ada-9X?

[R. William Beckwith]

  posting for Jon Anthony (jsa@gensym.com)
  ----------------------------------------

R. William Beckwith (beckwb@ois.com) wrote:
: My view of persistance involves (at least) these four elements:
: ... Various steps ...

Note that OMG has officially blessed the Persistence Services part of
the Common Object Services Specification.  So, the *what* that needs to
be done is done and furthermore, it is completely specified in IDL.  It isn't
just CORBA that makes an Ada/IDL mapping important, its the fact that a
whole plethora of services are (or have already been) standardized via IDL
and are being implemented (check out Tivoli Systems for instance...)
 
/Jon

Jon S. Anthony
Gensym Corp.
125 CambridgePark Drive
Cambridge, MA 02140

Re: Persistence for Ada-9X?

[Stephen Crawley]

In article Czo@ois.com, beckwb@ois.com (R. William Beckwith) writes:
>  posting for Jon Anthony (jsa@gensym.com)
>  ----------------------------------------
>
>R. William Beckwith (beckwb@ois.com) wrote:
>: My view of persistance involves (at least) these four elements:
>: ... Various steps ...
>
>Note that OMG has officially blessed the Persistence Services part of
>the Common Object Services Specification.  So, the *what* that needs to
>be done is done and furthermore, it is completely specified in IDL.  It isn't
>just CORBA that makes an Ada/IDL mapping important, its the fact that a
>whole plethora of services are (or have already been) standardized via IDL
>and are being implemented (check out Tivoli Systems for instance...)

I didn't see your (?) message to which Jon Anthony is replying.  (A lot
of "comp.lang.ada" messages never reach us at DSTO ...)

I would infer from what Jon is saying that CORBA Persistence Services 
provide "copying" style persistence; i.e. where saving and restoring
a data structure generates a new copy in the application program's 
address space.  

Many people in the DBPL research community would argue that
this style of persistence is inferior to "orthogonal" persistence
in which making an object persistent does not alter it's identity
properties (or any other properties apart from it's lifetime).  
Languages that provide orthogonal persistence include PS-Algol and
Napier88.

A few days ago, I presented a paper entitled "Orthogonal Persistence
and Ada" at TRI-Ada '94 which discusses the linguistic problems of
supporting O.P. in Ada83 and Ada9X.  While Michael Oudshoorn (my
coauthor) and I concluded that full O.P. is not feasible in Ada83/9X,
we are currently thinking about a more limitted form of O.P. that could 
be implemented using GNAT / GCC as a starting point.  

I will provide a URL for the TRI-Ada '94 paper in a week or so (when
I can find a publicly visible resting place for it.)

Could anyone who is interested in Persistence in Ada9X please
send me a brief email?

-- Steve

email: <sxc@itd.dsto.gov.au> or <stephen.crawley@dsto.defence.gov.au>