Disributed Smalltalk and OODBMS for VisualWorks and ObjectWorks\Smalltalk 
Author Message
 Disributed Smalltalk and OODBMS for VisualWorks and ObjectWorks\Smalltalk

A  r  t  B  A  S  E

D i s t r i b u t e d   S m a l l t a l k   a n d
O b j e c t - O r i e n t e d   D a t a b a s e  
M a n a g e m e n t   S y s t e m
f u l l y   i n t e g r a t e d   i n t o
V i s u a l W o r k s   a n d  
O b j e c t w o r k s \ S m a l l t a l k

ArtBASE extends the Smalltalk environment by

- persistent objects and classes
- multi-user access to shared objects and classes
- transaction mechanism
- optimistic concurrency control with object-level locking

ArtBASE has been designed to be fully consistent with the Smalltalk
programming environment from the point of view of the uniform syntax
as well as automatic object and memory management. The aim was not to
introduce a "database bridge" and "remote object access" but rather to
keep the programming comfort of Smalltalk where the programmer does not
have to care how the objects are created, accessed or reclaimed.

The architecture of ArtBASE has been designed to provide a maximum
permeability for distributed applications, however, to keep the binary
portability across heterogenous hardware platforms.

ArtBASE is the easiest way to build multi-user databases and
object-based information systems from your Smalltalk applications,
with heterogenous hardware platforms accessing shared objects.

Implemented fully in Smalltalk, all source code included.

A r t B A S E   -   a   S m a l l t a l k - b a s e d   O O D B M S

        ArtBASE has been designed and implemented as an industrial
object-oriented database management system which adds database features
to the Smalltalk programming environment. It keeps all the advantages
of the Smalltalk environment from the point of view of homogenity
(objects of the same kind, classes as description of the behavior of
their instances, uniform syntax and unified protocol of abstract
classes) and programming comfort.

        To create a database application from an existing one, some
of the objects from the application have to be declared to become
persistent. From this moment on these objects may be shared by other
users or applications.

        The image, its parts or even just a few objects may be shared
concurrently. The image may be dynamically extended to gain access
to other not yet known persistent objects. Virtual extension of the
image (opening an area) does not mean "loading all persistent objects
into the image", but rather indirect "late-binding" access to objects
at the moment when they are referenced in a message send, i.e. when
they are really needed.

        ArtBASE satisfies all features of industrial object-oriented
databases which are needed for building multi-user information systems
and other applications as well as new kinds of applications (e.g. CASE,
CAM, CAD, GIS, multi- and hypermedia systems etc.):

- concurrent access up to the object level for several users/applications

- distributed access - data and objects can be located as close as
  possible to the place of their most frequent usage to minimize data
  transfer in the network and maximize the performance

- transaction management - atomic units of retrievals or updates in
  the database, which guarantee the consistency of the database

- optimistic concurrency control - improves concurrency in a transaction
  management environment assuming that the transactions will not
  conflict at commit

- object locking - enables locking of objects for read, write or
  exclusive to ensure that the transaction will be able to commit

- recovery after a soft or hard crash

- sophisticated access authorization control up to the object level

        ArtBASE preserves the great advantage of high portability
of Objectworks\Smalltalk at the binary level across heterogenous
hardware platforms and it enables a concurrent multi-user access to
shared objects from diverse kinds of UNIX workstations, MACs and PCs
in a LAN environment.

        Furthermore, ArtBASE enhances the binary portability from the
image-level to the application level - the whole application or any
part of it may be stored in an ArtBASE area with the entire definition
of classes and may be accessed and loaded into images running on other
platforms. It may also be delivered or updated as files containing
particular objects, i.e. applications may be delivered as independent
binary modules.

C o n s i s t e n c y   w i t h   t h e  
S m a l l t a l k   E n v i r o n m e n t

- virtual extension of the Smalltalk object space to theoretically
  unlimited size

  > areas as logical objects spaces extending the Smalltalk image;
    each persistent object is placed within a specific area

  > no special "database system" with different environment, object
    manipulation and query language

  > consistent employment of the class/instance paradigm

  > behavior describing the schema of the database (classes) associated
    with corresponding areas

  > objects (instances) residing in their area

  > name spaces of globally accessible objects associated with
    corresponding areas (area dictionary)

D i s t r i b u t e d   a n d   M u l t i u s e r   O O D B M S

- distributed area representation - areas as logical object spaces
  reside on persistent memory media (disks) which might be distributed
  on diverse file servers in LAN (e.g. at the place of their most
  frequent use to minimize the data transfer)

- multi-user - many users may be logged to ArtBASE concurrently and
  they may access shared persistent objects and classes; all possible
  conflicts of such an access up to the objects level will be recognized
  and managed by ArtBASE itself

A r t B A S E   A r e a s

- area - logical object space which virtually extends the Smalltalk

- physical area - physical object space with unique object ID for each
  object within this area; the area is identified within the ArtBASE
  system with its area ID

- logical area - virtual area consisting of a collection of other areas
  (physical or logical); a logical area does not include objects
  directly, only by means of its physical areas and that is why there
  is no identity of a logical area within the ArtBASE system, it is
  identified only by its name at the ArtBASE system administration level;
  logical areas may be viewed as applications.

A r t B A S E   D a t a b a s e

- consists of a consistent collection of ArtBASE areas, i.e. the
  uniqueness of the area ID is preserved within each ArtBASE database

O b j e c t   P e r s i s t e n c e

- ArtBASE is able to convert Smalltalk objects to become persistent and
  to maintain these objects for use in later sessions

O r t h o g o n a l i t y   o f   t h e   P e r s i s t e n c e

- any Smalltalk object (even a class) may become persistent, there
  are no special "persistent object" classes

- trivial extensions of existing applications to a database application
  by simply declaring objects to become persistent and sending locking
  and changed messages.

T r a n s p a r e n c y   o f   t h e   P e r s i s t e n c e

- persistent and transient objects are treated in the same way, they
  belong to the same class (persistency is a property of the instance,
  not of the class)

- the same code (methods) operates in the same way on persistent as
  well as on transient objects

I n d e p e n d e n c e   o f   t h e   P e r s i s t e n c e

- automatic loading of objects to the image upon first message send to
  the object, no explicit "read" and "write" to the database

- automatic object caching and unloading to temporary area if the
  actual virtual image size exceeds the memory limits

- memory management of the loaded persistent objects transparent to the
  user (caching, temporary unloading to a disk-resident cache, unloading
  to the database after successful transaction commit)

O b j e c t   I d e n t i t y

- each persistent object has its object identity in the virtual address
  space of the whole database system

- the object identity is represented by the database object pointer -
  oop which identifies the object handle

I n d e p e n d e n c e   o f   t h e   O b j e c t   I d e n t i t y

- location independence - identity of objects is preserved despite
  changes to their location (in volatile or persistent memory); the
  physical location of the area representation (physical files) may
  change (reside on different file servers)

- value independence - the identity of objects is preserved through
  changes in values of object variables;

- structure identity - object identity is preserved through changes of
  object structure; any persistent object may change even its class or
  swap its identity with another object

T r a n s a c t i o n   M a n a g e m e n t

- any access to the database objects is made within transactions

- all changes to the database are local to the transaction until the
  transaction ends with successful commit or it is abandoned (rolled

- long lived transactions - transactions may survive during several
  sessions with all information saved in the image, i.e. during
  a transaction the user may freely save the image and start again in
  the same state of the transaction; only transaction commit will
  affect the database

O b j e c t   L o c k i n g

- to ensure the possibility of transaction commit (i.e. ensure that
  no conflict will arise during commit) objects may be locked for
  a particular user

- locks survive the transaction end and belong to the user during his
  session (until

read more »

Mon, 05 Feb 1996 00:24:55 GMT  
 Disributed Smalltalk and OODBMS for VisualWorks and ObjectWorks\Smalltalk

The following sounds like a common problem.  I have an ad hoc solution
but I am sure experienced Smalltalk users know better solutions.

Here is the situation.  I have used VisualWorks to create a user interface.
It includes several buttons that trigger certain actions.  These actions
should generate messages to the SAME instance of an object.

To be more specific, let us assume that I have defined the class A.
Button 1 triggers an action that creates an instance of A and then
assigns some values to instance variables of that instance of A.
In other words, the action triggered by button 1 looks like this:

        | a |
        a := A new.
        a putSomething: 3.
        a putSomethingElse: 5

Now, button 2 should trigger an action to be sent to the SAME instance
of A.  To be more precise, it should be able to retrieve the values
that button 1 put into a.  However, since a is a temporary variable,
that instance is not accessible (I believe).

My ad hoc solution was to put these permanent things into class variables
rather than instance variables but I am not sure that my approach is right.

Any suggestions will be greatly appreciated.

Eugene Veklerov
Bldg. 46A, Rm. 1123                     Phone:  510-486-7532
Lawrence Berkeley Laboratory            Fax:    510-486-5936

Berkeley, CA 94720

Mon, 05 Feb 1996 10:02:22 GMT  
 Disributed Smalltalk and OODBMS for VisualWorks and ObjectWorks\Smalltalk
I am not familiar with the VisualWorks GUI, but as I see it:

  1) You want an object which will "manage" A.  It must be solely
     responsible for creating and discarding A, and for providing
     information about A ( such as A itself, or restricted to
     various aspects of A ).   Thus, one of the instance variables
     of this "manager" should reference A.

  2) You do not want any other objects creating and using other instances
     of A's class.  This is easy if your objects only ask the manager
     about A.  Thus, each of these objects will need an instance variable
     which references the "manager".

I would suggest something like:

Object subclass: AManager
   instanceVariables: 'a button1 button2 buttonX "etc." '

SomeKindaButtonClass subclass: AMakingSortOfButton
   instanceVariables: 'theBoss'.

SomeKindaButtonClass subclass: QueryingAboutASortOfButton
   instanceVariables: 'theBoss'.

AManager class is responsible for item 1.  In addition, it may be useful
if an AManager were aware of all the objects which will be making inquiries
about A.  Thus, button1 might be an instance of AMakingSortOfButton while
the rest of the buttons are instances of QueryingAboutASortOfButton.

AMakingSortOfButton objects would know how to tell theBoss that a new
instance of A is recquired, such as by:

        theBoss createNewAWith: 3 with: 5.

QueryingAboutASortOfButton objects would know how to ask theBoss about A:

        tempA := theBoss a.

or      theBoss somethingINeedToKnowAboutA.

I use a technique similar to this approach throughout an unstructured
grid generation algorithm I have written.  My code is much cleaner and
far more bullet-proof now that I restrict direct knowledge about an
object which contains popular information to a manager, rather than letting
every object under the sun that will be recquesting that information know
directly about the information.  When the information changes, only one
object needs to be informed ( and it is probably the manager object
instigating the change anyway ).  No other objects need to be told
to update thier references to the information, as they will still be
talking to the same manager.

Another benefit you should see is a reduction in code duplication.  At
least, this my experience.

Hope that helps !

Tue, 06 Feb 1996 02:54:15 GMT  
 [ 4 post ] 

 Relevant Pages 

1. US-FL VisualWorks smalltalk and GemStone OODBMS opportunities


3. US-TN Intermediate VisualWorks smalltalk and HP-Distributed Smalltalk opportunities

4. ST VisualWorks- Smalltalk, VisualWorks and Envy

5. OODBMS for Smalltalk

6. Object Persistence (OODBMS alike) for Smalltalk





11. Extolling the virtues of VOSS (Was Re: OODBMS For Smalltalk)

12. OODBMS for use with smalltalk


Powered by phpBB® Forum Software