All Packages Class Hierarchy This Package Previous Next Index
The Managed provides for Lifecycle and Identity that works either within the Managed object's address space or from outside its address space. If an object references a Managed object from another address space, its stub/proxy uses this identity mechanism to locate the Managed object. If the persistent state of an object references a Managed object, it uses this identity mechanism in its persistent state.
The Managed object implementation supplied by a BaseCollection should override the Manageable's implementation with its own implementation for the following methods:
A Managed object is treated as a reference by most clients. That is, when your OOD model calls out a "by reference" relationship from one object to another, you should assume that the source object of the relationship has a Managed object as part of its state. If this reference is considered to be "essential" (non derivable), then use the readManaged() and writeManaged() methods on EDStream types instead of the readObject() and writeObject() methods.
If your OOD model calls out a "by value" relationship, then you can use a Manageable object instead (and correspondingly, the readObject() and writeObject() methods on EDStreams).
While all Managed objects obey a defined common interface, they are implementated by a BaseCollection to work with the particular storage sub-system (or family of storage sub-systems) that the BaseCollection uses. These implementation differences are hidden from the client by the BaseCollection and Managed interface standards.
Each storage sub-systems will provide libraries, tools, and documentation that can be used by AAs to construct Managed objects from Manageable objects for that particular sub-system. In most cases, this will not require the AA to provide any actual code.
The essential common features of Managed objects is that they have a unique Identifier, they exist in one particular BaseCollection, and they support the Identifiable, Manageable, and Lifecycle interfaces.
Every Managed object has a single BaseCollection that provides a unique Identifier key within the scope of that BaseCollection. Because a BaseCollection can itself be a Managed object, this forms a a pure tree of BaseCollections. The keyPath between a BaseCollection and a decendent Managed object forms an Identifier that is unique within the scope of that BaseCollection.
In addition, many Managed objects will support object services (eg, persistence, concurrency, security, transactions, etc.), because they will be contained in a BaseCollection that supports these services.
public abstract String getIdentifier(BaseCollection relativeTo) throws RelativeToError
The Managed object's getIdentifier() implementation has the following rules:
- if (myBC is null && myBC is the relativeTo) return myLocalKey; - if (myBC is null && myBC is not the relativeTo) throw new RelativeToError(); - if (myBC is not null && myBC is the relativeTo) return myLocalKey; - if (myBC is not null && myBC is not the relativeTo) return myBC.getIdentifier(relativeTo) + "/" + myLocalKey;
BaseCollection
within which
the identifier should be scoped.
String
that can be used to resolve to the
identical Managed object against the relativeTo BaseCollection
All Packages Class Hierarchy This Package Previous Next Index