Information Technology Reference
In-Depth Information
Specialized frameworks such as those for
business
(enterprise) components
[4,6,
10]
are associated with more specialized programming models. The computing en-
vironment (often called a
container
) provides more services to developers, but also
imposes more constraints on developers. Typically, the more sophisticated the ser-
vices provided (e.g., transactions or persistence), the greater the constraints imposed
on developers, and the less they can simply “do their own thing”
[24]
.
Business components are usually comprised of an
interface
(used by the appli-
cation's clients) and an
implementation
(provided by developers). In such cases
we must therefore distinguish between a
client
and
developer
programming model.
The developer programming model requires developers to deal with an architected
component life-cycle. The life-cycle dictates a state transition diagram that will be
followed as components are created, activated, and destroyed. As the component
makes transitions from one state to another, the container invokes specific methods
on the component: developers must ensure that their implementation of the compo-
nent's interface provides the appropriate semantics. The client programming model
specifies the way that clients must access the container in order to create, locate,
update, or delete components.
In this section we discuss two programming models for disconnected business
applications, focusing on how the programming models reduce (for both developers
and clients) the effort required to deal with “disconnection” (i.e., the issues discussed
in Section
3
).
4 . 1 S e r v i c e D a t a O b j e c t s : C o n c e p t s
We begin our discussion with Service Data Objects (SDOs). A paper
[35]
describ-
ing the motivation for, and providing context about, SDOs was released in 2003,
along with version 1.0 of the specification. Version 2.0 of the SDO specification was
released in 2005
[36]
. In general we will refer to SDO 2.0 in this chapter.
Although SDOs were initially presented as a joint proposal from IBM and BEA,
they are also under development as a Java Specification Request (#235)
[37]
.Ref-
erence
[34]
provides an overview of the SDO specifications; and IBM's reference
implementation can be downloaded from the Eclipse site
[38]
.
A
Data Access Service
(
DAS
) is the SDO “container” construct. As shown in
Fig. 7
, a data access service mediates between persistent datastores and applications
by materializing and managing
data graph
instances. Data graphs are comprised of
DataObjects
, the “DO” of the SDO specification. Note, that although the DAS is a
key concept of the SDO architecture, it is not currently covered by the SDO 2.0 spec-
ification. The various sample mediators which have been constructed
[2,41]
appear
to have DataStore-specific APIs.
A DAS provides the following function to applications:
