eberard@ajpo.sei.cmu.edu (Edward Berard) (09/04/89)
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