Information Technology Reference
In-Depth Information
work-flow. In this scenario, in fact, data replication synchronization begins to re-
semble the message-based synchronization (with all of its disadvantages) discussed
above.
In contrast, with method replay, the
purchaseOrder
method is modified to
conditionally perform the credit check and modify the existing balance only when
connected (and thus during synchronization as well). This additional application
logic is ignored when executing on the disconnected device. All that this approach
requires is the ability to determine whether a method is executing in a connected
or disconnected environment. The connected version performs the required credit-
check; the disconnected version branches around that code (placing the order without
the credit-check); and, during method replay, the credit-check will be transparently
performed before placing the order.
It seems therefore that the following tension exists with respect to deploying busi-
ness applications to disconnected devices. If you wish to use a single programming
model so as to develop and maintain a single version of the application, the applica-
tion will modify much transactional state. During synchronization, data replication
then is more likely than method replay to abort the work performed on the device be-
cause of false conflicts. This problem can be reduced, but only by creating connected
and disconnected versions of the application. Here too, method replay is more useful
than data replication because the branch logic is more easily packaged within a single
method or business process than as extraneous processes that must be hooked into
the business work-flow during synchronization. Executing the bulk of the application
on the server, with only a minimal application executing on the client, mitigates this
problem but only by drastically limiting the usefulness of disconnecting the applica-
tion in the first place.
The use of method-replay synchronization does constrain the application to take
extra care when accessing data that is outside the shared datastore. If such data be-
comes part of the client-side datastore, it may not be used correctly during replay
because the external value may have changed since the original disconnected ex-
ecution. For example, if an application sets fields based on the current time (e.g.,
timestamps) or using unique identifiers
[42]
, the replayed application will use the
current
values of the external data (e.g., the current time), not the values that were
originally used on the device. This may or may not be a problem. If the UUID is
used to set an EJB's primary key, and that EJB is referenced (and logged) by the
application, method replay synchronization will fail because that EJB's identity on
the server will be based on a new UUID value.
Data replication experiences a similar issue when dealing with unique identifiers.
Because the locally unique identifier (LUID) client ID may be different from the
globally unique identifier (GUID) server ID, the server must maintain an ID mapping
table for all items exchanged between itself and the client. Otherwise, the client's
