Understanding the Programming Model
Why Managed Objects
An enterprise can be most directly modeled using objects, where the
real-world entities each have a corresponding object, and real-world actions
each have either a corresponding method on an associated object, or
sometimes an entire object that represents the task.
These objects need to have the same properties as the entities they
model:
- Because the entities include both single entities (e.g., a customer)
and groups of entities (e.g., all customers), both single objects and collections
of objects with a query mechanism are needed.
- Because the entities have persistent state, their corresponding objects
need persistent state.
- Because the entities have a persistent identity (e.g., our bank's customers,
a particular customer number, our bank's checking accounts and a particular
checking account number), their corresponding objects need persistent identifiers
(e.g., http://ThriftBank.com/bankServlet;/customers identifies the collection of
all customers,
http://ThriftBank.com/bankServlet;/customers/212-44-5673
identifies a particular customer,
http://ThriftBank.com/bankServlet;/checkingAccounts identifies the collection
of all checking accounts, and
http://ThriftBank.com/bankServlet;/checkingAccounts/C-9904529552
identifies a particular checking account).
- Because the entities are named differently from different contexts
their corresponding objects need an aliasing mechanism (e.g.,
http://ThriftBank.com/bankServlet;/customers/212-44-5673/checking,
and http://ThriftBank.com/bankServlet;/customers/119-48-8409/checking are
aliases from different married customers for a single joint checking
account identified by account
http://ThriftBank.com/bankServlet;/checkingAccounts/C-9904529552).
- Because the actions of users on specific entities need to be controlled,
access control is best supported on their corresponding objects and methods.
- Because policies need to be enforced for entities (security access
must be renewed each year), policies on their corresponding objects are
best supported in the object domain.
- Because the actions of users need to be considered atomic, access to
their corresponding object methods or command objects should support the
ACID (Atomic, Consistent, Isolated and Durable) transaction
properties.
Managed objects provide these properties for objects.
Without Managed objects, data can have the above properties and classes
can have some of these properties, but objects cannot. The relationship
between data and real-world entities is often indirect, introducing an
undesirable indirection. For example, it is often difficult or impossible
to translate access control or policies onto data read-write access control.
This is similar to how CICS controls access to client requests and the
corresponding data is only accessible by the CICS server administrator.