Programming Models and Synchronization Techniques for Disconnected Business Applications - Advances in Computers - page 112

F IG . 8. Proposed client-side data access service.
More fundamentally, such a client-side DAS would have to address the need to
support conflict resolution when conflicts do occur, which is one of the main fea-
tures of a disconnected programming model (Section 3 ). This is a difficult problem
because conflict resolution appears to require detailed knowledge of application se-
mantics, and cannot therefore be easily done by middleware. Unfortunately, there is
no “silver bullet” for this challenge. Relative to technologies such as DB2e [7] or
cached RowSets [33] , SDOs provide synchronization middleware with an API to a
DataObject's change history. The SDO ChangeSummary API, however, assumes that
synchronization is done using data replication rather than method replay (Section 3 ).
New ideas for change management, such as method replay, do not easily fit into the
architected change summaries.
Can EJBs be used as a disconnected programming model? The claim by the SDO
whitepaper that EJBs are not suitable for “disconnected” environments is really a
claim that EJBs use pessimistic concurrency control and lock data. As shown by
work in EJB caching [25] , EJBs (like SDOs), certainly can use optimistic concur-
rency control mechanisms. Granted that the EJB specification assumes a connected
environment, we do not see why the EJB programming model cannot be projected
to disconnected environments as well. As discussed in Section 2 , the chief chal-
lenge introduced by disconnection is client synchronization with the server. Although
EJBs do not provide a change history API, EJB containers can transparently provide
this information in a straightforward fashion, and can thus transparently provide de-