Information Technology Reference
In-Depth Information
bean-provider's viewpoint—“aspect-oriented” programming [1] . The only difference
between the connected and disconnected versions of the application are that discon-
nected execution dynamically constructs a log that can be used to do synchronization
based on the method-replay approach.
Because it has access to the container's transaction mechanisms, EJBSync respects
the transaction structure that is dynamically created as the application executes.
Thus, LogRecords are scoped with respect to a given transaction; within a trans-
action, they are ordered in the sequence that the methods were invoked. This allows
all methods invoked in a given transaction to be atomically replayed on the server.
As outlined in the EJB specification, remoteable EJBs are passed by reference
between address spaces. This implies that, when they are serialized, the serialized
form contains only the EJB reference, not the state. This presents some difficulty
for LogRecords, because LogRecords are implemented as Entity EJBs in our mid-
dleware. The middleware must transfer the saved state of the LogRecords from
the client to the server during synchronization. In order that Entity EJB states
may be serialized, we introduce the EJB Memento [13] construct. EJB Memen-
tos contain all the values of the abstract persistence schema [10] , and implement
the java.io.Serializable interface. Entity EJBs are passed by value by ex-
tracting their EJB Mementos and serializing them instead. EJBSync tooling provides
automatic generation of EJB Mementos, as well as Home methods for creating EJBs
from their deserialized EJB Mementos.
When logging EJB method calls, the EJB references are saved, rather than the
values. This is because the replay should be invoked against the current state of the
EJBs, not the state at the time the method calls were logged. Normally EJB refer-
ences contain information about the address-space in which the EJB exists. Since we
need to replay against a different address space (the server rather than the client),
our middleware changes the serialization to remove the address-space information,
so that EJB references are deserialized as references to server EJBs with the same
primary key, residing in a server-located Home with the same JNDI name. (Normally
these references would deserialize into remote proxy objects.) This information, to-
gether with Java's reflection mechanisms, enables server-side reconstruction of the
EJB on which the method was invoked as well as the method's parameters. A method
is replayed by executing invoke on the corresponding Method .
This approach enables an application-independent synchronization protocol.
(1) The synchronizing client invokes the client-side EJBSync middleware when it
wishes to synchronize with the server. All LogRecords created since the last
synchronization are transmitted to the server, in addition to the client's id and
current synchronization-session id.
(2) The server-side Replicator SSB iterates over the set of LogRecords, batching
the LogRecords of a given transaction together, and ordering the transactions
Search WWH ::




Custom Search