Browse Prior Art Database

Process to Support Objects External to an Object-Oriented Environment

IP.com Disclosure Number: IPCOM000111758D
Original Publication Date: 1994-Mar-01
Included in the Prior Art Database: 2005-Mar-26
Document File: 8 page(s) / 176K

Publishing Venue

IBM

Related People

Crothers, HE: AUTHOR [+10]

Abstract

Disclosed is a mechanism to reference and manipulate Logical Data Objects (LDOs) from within an Object Oriented System using Logical Data Reference Objects (LDROs).

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 47% of the total text.

Process to Support Objects External to an Object-Oriented Environment

      Disclosed is a mechanism to reference and manipulate Logical
Data Objects (LDOs) from within an Object Oriented System using
Logical Data Reference Objects (LDROs).

Description of Terms

CTTN   Copy-Transform-Transfer-Notify.  This is a process which has
up to four steps:

1.  Copy the LDO from the originating RM.

2.  Optionally, transform the LDO to be format compatible with the
    destination RM.

3.  Transfer the LDO to the destination RM's node, and copy (import)
    it into the destination RM.

4.  Notify the System to update the LDRO with the LDO's final state
    data.

LDO    Logical Data Object.  This is an object that does not consist
of a set of discrete attributes, but rather contains one "attribute"
of potentially infinite size.  In relation to the System it will
generally be a drawing, though it could also be Numerical Control
(NC) programs, engineering specifications, or microcode.

LDRO   Logical Data Reference Object.  This is the System's
object-oriented reference to the LDO.

RM     Resource Manager.  This is an external data store that manages
the actual Logical Data Object (e.g., CDM, MVS, CADAM, etc.).

Pull versus Push

      LDOs are pulled rather than pushed when they are moved from
node to node.  Pulling an LDO has certain advantages over pushing the
LDO, not the least of which is the fact that the sending system is
relieved of having to know about every Resource Manager in the entire
network.  Figs. 1 and 2 demonstrate the administrative overhead
associated with push and pull, respectively.

Weak References

      Logical Data Reference Objects (LDROs) within the System are
weak references (Fig. 3).  This means that there is no validation
that the Logical Data Object (LDO) actually exists, and the System
will not drive any synchronization with the Resource Manager (RM) to
ensure that LDROs are maintained along with the LDOs.  Thus, LDROs
which have no corresponding LDOs could exist within the System.  The
"? ? ?" indicates that the LDO does not exist in the RM, even though
there is an LDRO which thinks it does.  Additionally, LDOs will most
likely exist within the Resource Manager (RM) with no corresponding
LDROs within the System.

      The reason LDROs are weak references is that weak references do
not require extensive interfacing code to keep both the System and
the RM in synchronization.  It is felt that this is a much too
difficult task to provide an adequate solution by the first release.
However, the System does provide a mechanism for RMs to keep the
System in synchronization by externalizing the Create, Delete, and
Notify methods of the LDRO class.

Non-Unique References

      Logical Data Reference Objects (LDROs) within the System will
be "non-unique" references (Fig. 4).

      Once an LDRO exists, it can be associated with other objects,
called Using Objects (for example, pl...