Overview Of bcfw
This is a framework so there is no test subdirectory.
Testing for this is in COM.ibm.jaws.services.filepobc.test.
Design Point For BaseCollections
We think that most BaseCollections should be wrappers around
an exiting database system, file system or OODB. To support
robust collections of objects whose state and identifiers are
persistent, there is no reason to reimplement plumbing code that
already works well and is generally available. The mofw goal is
to provide a standard interface contract between OO application
developers and services so that code reuse (and therefore value)
is increased on both sides of the contract. Such a standard
permits object support using a straight forward wrappering of
existing storage systems.
Sometimes you hear talk about storage access patterns
for object applications. This is a myth
invented by myself and my colleagues during a past life when we
were trying to sell OODBs. It makes about as much sense as talking
about access patterns for procedural applications. Implementing
an application using either object or procedural techniques does
not change its storage access patterns. Most OLTP
applications need efficient random rifle-shot access and update,
as well as robust servers, because that is what these applications do
and what they need, regardless of whether they are implemented with
object or procedural techniques. An application that needs heavy
traversal through data, or efficient queries or robust identifiers
for its entities or whatever, then these do not change if object
techniques are used to implement it. If a storage system
fills an important market in the procedural world, then it will
fill that same market in the world of objects.
Wrappering these servers is a sensible way to support objects
because:
- It is quick to implement and bring to market, and
- It preserves the valuable characteristics of these servers.
Description of Interfaces
This framework is for BaseCollection service providers,
not for BaseCollection clients.
The following conventions allow BaseCollection providers provide
common functions in a similar way to simplify the AA job:
-
The implementation of COM.ibm.jaws.mofw.Dependent.setDependentContext()
for a BaseCollection includes setting the dependent context
that it gives to its Managed objects to be the same as its
dependent context. This allows the same dependent context to
propagate down a tree without the AA having to do anything.
In the future, different dependent contexts may be need in the
same address space.
-
For heterogeneous BaseCollections, the interfaceKey parameter
of the createFromXXX() methods is used to find the Managed
class name in the dependent context. The convention that
simplifies AA administration is for the dependent context to
contain the binding key of ::
with the value of the Managed class name. This has the following
flexibility:
- The package name for the Managed class need not be
known to the Manageable object programmer (OP).
The AA can map the interfaceKey onto a class name
in any package.
- The same interfaceKey can be used for the same class
made Managed for multiple BaseCollections in the same
address space.
-
A shared cache manager can be found from the dependent
context by resolving on a key that is the package name
of the shared cache manager.
The following interfaces are introduced to help BaseCollection
providers provide caching BaseCollections and cache managers that
can be mixed and matched:
-
A BaseCollectionDel (using delegation)
allows BaseCollections to be supplied that use
finite memory/backingstore resources. This is important
for serious servers that cannot be taken down and restarted
casually. A BaseCollectionDel can use the delegation implementation
model that separates a Managed object into 2 or 3 server-side
runtime objects:
-
A Cached object that is either the Manageable object
(eg, EmployeeImpl) or the Manageable object extended
with whatever services the BaseCollection provides.
-
A CacheEntry that contains cache status information.
This can either reference a Cached object or can
extend a Cached object.
-
ManagedDel is a skinny (a method table pointer and
3 java references to its BaseCollection,
its Identifier key within that BaseCollection and
its Cached object) Managed object that implements
identity functions (getIdentifier, isIdentical and
getConstantRandomId) functions and lifecycle functions
(remove) directly and implements the Manageable
methods via delegation to its Cached object.
This separation allows the number of the typically much larger
Cached objects to be kept constant during steady state
operation and still support the same programming model
wrt client references for objects with persistent references
that java supports for objects with transient references.
-
A BaseCollectionEC (external cache) is a BaseCollectionDel
that can use an external CacheManager for sharing memory/backing
store resources across multiple BaseCollectionECs.
This has the following advantages:
-
These BaseCollections can be simpler because the
cache management is factored out.
-
Multiple instances of these BaseCollections can share the
same cache manager, which allows the memory/backingstore
resources to be allocated to the Managed object that most
need it across objects in multiple BaseCollections.
-
Along with the BaseCollectionEC interface, an external CacheManager
interface is introduced that can be shared across multiple
BaseCollectionECs. The interface contract between these
implementation classes allows either the BaseCollectionEC
or CacheManager to provide cache management policy. Typically,
the CacheManager provides a simple context-independent algorithm
(eg, lru) that the BaseCollectionEC overrides when it knows more about
access patterns (eg, scan optimization during query execution).
These BaseCollectionDel, BaseCollectionEC and CacheManager interfaces
are not seen by the BaseCollection client. They are for cooperation
between the implementation objects.
The Syncable interface is introduced to allow a BaseCollection
or Managed client to ensure that these objects are consistent with
their stable storage.