From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE,
	MSGID_SHORT autolearn=no autolearn_force=no version=3.4.4
Xref: utzoo comp.lang.ada:2622 comp.sw.components:129
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!tut.cis.ohio-state.edu!pt.cs.cmu.edu!sei!ajpo!eberard
From: eberard@ajpo.sei.cmu.edu (Edward Berard)
Newsgroups: comp.lang.ada,comp.sw.components
Subject: Further Thoughts on Moving Objects
Keywords: objects, networks, distributed processing
Message-ID: <569@ajpo.sei.cmu.edu>
Date: 4 Sep 89 15:36:58 GMT
List-Id: <comp.lang.ada>

First, let me state some general observations:

	- Many of the problems associated with "object movement,"
	  e.g., deobjectification (i.e., the decomposing of a "large"
	  or "complex" object into smaller, more primitive objects)
	  and objectification (i.e., the "re-constitution" of a large
	  object from smaller, more primitive objects), are identical
	  to those problems faced when attempting to store objects in
	  non-object-oriented database management systems
	  (non-OODBMSs). More specifically, there is a class of
	  problems which arise when objects (and classes) must be
	  given to and/or retrieved from an interface which does not
	  recognize "large" or "complex" objects, or, for that matter,
	  objects in general.

	- Well-designed objects and classes are designed "in
	  isolation," i.e., apart from any specific application. While
	  the designer of the object or class may know about the
	  underlying implementation of the object or class, he or she
	  should avoid attempting to "tune" the object or class for
	  any specific application. (This not only enhances
	  reusability, but also often has a positive impact on
	  reliability.)

	- Well-designed objects and classes provide the necessary
	  items (e.g., operations, constants, and exceptions) in their
	  interfaces (specifications) to accomplish any necessary work
	  involving the object or class. Note that since well-designed
	  objects and classes ordinarily provide only simple
	  (primitive) items in their interfaces, a specific task may
	  require (possibly complex) combinations of these simple
	  items.

Suppose, for whatever reason, I wish to move an object (or class) from
one node on a network to another node. What kinds of situations might
I find? The trivial case is one where the object is itself a simple or
primitive object which is recognized by the interface (i.e., the
communication link), and no transformation is necessary.

If the object is not a composite object (i.e., from an external
viewpoint, the object is not (conceptually) composed of other
objects), there may be operations in its interface which will return
the state of the object in the form of primitive objects which are
recognizable by the communication link. There are, however, special
problems which can arise, e.g.:

	- The object is conceptually not a composite object, but its
	  implementation involves (possibly complex) combinations of
	  objects. In some cases the goal of information hiding may
	  actually prevent the object from being efficiently
	  "deobjectified."

	  Consider a "post office object." Suppose that the interface
	  for such an object contains only the following operations:

		- is_there_any_mail (for a given address)
		- send (this mail)
		- pick_up_mail (for a given address)

	  From the outside, the post office appears to be a single,
	  monolithic object. However, suppose that the designer of the
	  post office included such items as mailboxes, collections of
	  mailboxes, and clerks in the underlying implementation of
	  the post office? How would one represent the state of such
	  an object so that it could be moved (from one node in a
	  network to another)? One possible answer is that through
	  successive invocations of the "pick_up_mail" operation, one
	  could remove all the mail from a post office on one node,
	  deobjectify this mail, transmit the deobjectified mail over
	  the network, objectify the mail at the receiving node, and
	  through successive invocations of the "send (this mail)"
	  operation on an "empty" post office, create a copy of the
	  original post office.

	- If the object is an "object with life" (i.e., an object
	  which is capable of spontaneously changing its own state),
	  the internal state of the object may be constantly (and
	  rapidly) changing. How does one effectively capture and
	  transmit this state? Consider an air traffic control (ATC)
	  application. An "airplane" is a classic object with life.
	  How does one transmit an airplane object from one node to
	  another?

There are other questions and issues (e.g., the non-determinism
inherent in having two copies of the "same" object on two different
nodes). There are also quite a number of possible solutions. Since
object movement may not be something which can be avoided completely,
its ramifications should be considered in both object and system
design.

				-- Ed Berard
				   (301) 353-9652