Information Technology Reference
In-Depth Information
(during synchronization) shows
insufficient
stock to fulfill the customer's order. The
method-replay approach will detect—as it should—a “conflict,” in the sense that the
method's business logic should only place an order if sufficient stock exists to fulfill
the order. Thus, although the order was committed on the disconnected device, it will
not
commit on the server.
Broadly speaking, two approaches exist to handle such “insufficient stock” scenar-
ios for method replay. In the first, the method's business logic throws an exception
(e.g.,
OutOfStockException
) instead of following the typical code path that
fulfils the order. While this approach makes life simpler for application developers,
and is arguably appropriate for connected applications, it will result in a synchroniza-
tion error for disconnected applications that may be hard to recover from. In contrast
to connected applications, here the client concluded their session thinking that work
had successfully committed (because sufficient stock was available). The client may
be very confused when a mysterious exception is logged when she synchronizes sev-
eral days later. (Note that conflicts detected using the data replication approach have
the same problem.) We therefore favor the second approach, in which a business's
work-flow is integrated with, and becomes part of, a method's business logic. Thus,
when stock is available, the order is added to the “fulfilled order” queue; when in-
sufficient stock is available, the order is either added to the “back-order” queue or
to the “customer issue” queue. With this approach, the order will be committed on
the disconnected client as before. However, if insufficient stock exists when synchro-
nizing with the server, the order will continue to be processed exactly as if it was a
connected application. The programming model is thus transparent with respect to
the disconnected execution environment.
4.
Disconnected Programming Models: Service Data
Objects and Enterprise JavaBeans
A programming model can be viewed as a contract between a computing environ-
ment and developers who write programs that execute in that environment. On the
one hand, the contract specifies “services” that the computing environment must pro-
vide to developers. On the other hand, the contract imposes “constraints” on the type
of programs that developers may write. A programming language is thus associated
with a programming model. For example, the Java programming model specifies
that the Java Virtual Machine will automatically “garbage collect” an object's mem-
ory when that object is no longer referenced by other objects. Java programs, for
their part, must do
lexical
scoping because the programming model simply forbids
any other type of scoping, such as
dynamic
scoping.
