Information Technology Reference
In-Depth Information
data (e.g., Agent 86) may have different values in memory. In contrast, EJB Entity
Beans returned by different calls to the EJB server will always have the same value
within the same transaction.
Although it may be possible to change the SDO architecture into a single-level
store architecture, this will require defining identity for the entity DataObjects. In
addition, runtime middleware would be needed to manage the DataObjects. The mid-
dleware would need to track DataObjects by identity, and force returned DataObject
references to point to in-memory copies if they exist.
EJBs and SDOs both use a similar meta-model, sometimes called a Navigational
Database
[31]
. The database consists of entities (discrete “things”), with pointers
and paths which can be used to navigate between entities. Both EJBs and SDOs have
a notion of a special “containment” relationship, as contrasted with a “reference”
relationship: entities must be contained within exactly one other entity. Entity EJBs
are always contained within an EJB Home specific to that entity, whereas SDOs
have a more general containment structure (DataObjects must be contained by a
DataGraph). Reference relationships are largely unrestricted in both EJBs and SDOs.
Since EJBs are objects, they may have (significant) business logic embedded in
them. For example, an entity EJB which contains a ”birthdate” property as part of
the abstract persistence schema may have a
getAge()
method. The business logic
which implements
getAge()
is embedded in the EJB, and calculates the age based
on the current date. Stateless session EJBs also have business logic, but do not have
an abstract persistence schema. In contrast, SDOs only have properties (
getXXX()
and
setXXX()
methods or equivalent), and lifecycle methods (create and remove
DataObjects and/or properties). The developer may not specify the implementation
of these methods, nor may they add non-property methods. An SDO-based applica-
tion must push such application logic into higher-levels of the application, since it
cannot be packaged with the appropriate component.
Both EJB and SDO attempt to hide the details of the persistent datastore from
the client application. For EJBs, the EJB Specification
[10]
specifies Home and EJB
component (EJBObject) APIs which are independent of the underlying datastore. For
SDOs, the Data Access Service provides the API to the underlying datastore, ideally
in a way which is independent of the datastore.
SDOs are intended to work with meta-data describing the DataObjects that pop-
ulate the data graph. The meta-data itself could be populated from various model
frameworks, including XML schema, Eclipse Modeling Framework (EMF), and aug-
mented relational schema
[37]
. In examining the code produced by
[38]
and other
SDO samples, however, we noted that applications were certainly not required to
supply this meta-data, nor took advantage of its potential. EJBs use meta-data de-
rived both from invoking the Java Reflection API on the component interfaces and
