Information Technology Reference
In-Depth Information
5 . 4 U s e f u l D i s c o n n e c t a b l e B u s i n e s s A p p l i c a t i o n s
We conclude by arguing that only approaches similar to
EJBSync
enable devel-
opment of useful disconnectable applications, because of the inevitable issues that
arise as server-side function is moved to the client. A continuum exists with respect
to the degree to which server-side function is moved to the client. Browser-based ap-
plications exist at one extreme, in which almost all of the application resides on the
server. This “thin-client” approach has certain advantages, but the application can-
not execute on a disconnected device. To enable disconnectable applications, more
of the data and more of the application logic must reside on the client. At the other
extreme of the continuum,
all
of the application executes on the device. This may
not always be practical, but can be done for certain types of applications (e.g., for the
order entry
example used in this chapter). However, as we have shown, this approach
causes the maximum amount of data changes to take place on the device (e.g., stock
level changes). As more changes are made to the device's database, it becomes more
likely that false conflicts will be detected by data replication middleware (false in
the sense that human intervention could easily resolve them). Relatively speaking,
method replay will cause fewer false conflicts to occur, because the replays happen
against up-to-date server data.
Consider the middle of this continuum, in which some application logic is moved
to the disconnected device, but some remains on the server. For example, take the
usage of a customer's “available credit” balance in validating an order. The credit
balance could be replicated to the client, and orders placed only if the customer has
sufficient credit. If the balance is sufficient, the credit balance would be decremented
by the value of the order. Obviously this requires that
more
data be replicated to
the client. For data replication, this also raises a problem similar to the stock-level
problem discussed above. Because a customer's credit balance is modified by each
placed order, orders placed for the same customer by different clients will always
result in a (usually false) conflict during the synchronization of the second client.
This conflict is usually false because only the exhaustion of the customer's credit
balance is actually a problem. Two debits to the credit balance that do not exhaust
the customer's credit could be combined arithmetically during synchronization.
In order to eliminate this false conflict for data replication, the credit-balance
check could be eliminated from the disconnected client version of the application.
Since the
business
still requires that the balance be checked and updated before ful-
fillment of the order, a separate server-side process, triggered by synchronization,
must be put in place to do the credit-balance check and update. The code itself is
not the problem. The problem is that this code is separate from the disconnected and
connected versions of the application. It is not embedded in the original order-entry
application flow, and it is not necessarily easy to fit it into the post-synchronization
