Information Technology Reference
In-Depth Information
velopers with synchronization between the client and server. In fact, unlike SDOs,
EJB containers can provide the information needed to implement either the data-
replication or method-replay approaches.
Thus, an evaluation of the suitability of SDOs or EJBs for disconnected appli-
cations should realize that the differences between the EJB and SDO programming
models (Section 4.3 ) are orthogonal to the problems of replication, synchronization,
and conflict resolution. What matters is whether the programming model precludes
deployed components from interacting with synchronization middleware in a way
that provides transparent synchronization function. From this perspective, EJBs are
at least as suitable as SDOs for developing disconnected applications.
Recall that the EJB programming model is explicitly concerned with identifying
and facilitating the distinct roles that are required to develop and deploy an appli-
cation. The programming model specifies contracts that separate, for example, the
bean-provider role (provider of the application's business logic) from the container-
provider role (provider of the deployment tooling and runtime that supply deployed
EJBs with functions such as transaction and security management). Stage 3 synchro-
nization function can be similarly abstracted as a container-provided function that
bean providers can take for granted, and that is transparently provided by the middle-
ware. The EJB programming model is thus well suited for projection to disconnected
devices: the existing role separation enables us to enhance existing containers with-
out changing the API and semantics used in connected EJB applications.
We validated this hypothesis by building EJBSync —prototype middleware that
projects the EJB programming model to disconnected devices using the method-
replay approach. Because an EJB's state is backed by a datastore (typically a rela-
tional database), data replication can also be used to synchronize an EJB application
that executed on a disconnected device to the server. As the EJBs are modified, they
modify the backing datastore, and that datastore can be synchronized with existing
middleware such as DB2e. However, for the reasons presented in Section 5 , syn-
chronization based on method-replay enables a more successful programming model
projection than one based on data-replication.
4 . 5 EJBSync: M i d d l e w a r e f o r D i s c o n n e c t e d E J B s
EJBSync (see Fig. 9 ) is middleware that is both application-independent and
application-transparent. That is, an EJB business application developed for a con-
nected environment can be deployed to a disconnected environment with no (or few)
changes.
As discussed in Section 4.2 , EJB methods are specified in an interface definition
that is invoked by clients. EJBSync extends the tooling that deploys EJBs to a con-
nected container in the following way. Whenever the deployed component (i.e., the
Search WWH ::




Custom Search