Java Reference
In-Depth Information
after receiving your request, or if a network problem has cut off the route between you
and them.
It's impossible to know if a response is about to arrive, or if it will never arrive. As a
result, you need to be careful when making remote invocations. Error conditions
aren't uncommon, and you must be careful to avoid ending up in an inconsistent
state. To ensure this is the case, almost all enterprise applications that make use of
remoting use transactions to coordinate any resources they access. Advanced remot-
ing models assist the user here by allowing the transaction context to be propagated
across to the remote machine. At this point, you're running in a
distributed
transac-
tion, namely, one that's spread across more than one machine. The transaction is
coordinated such that both systems can recover from a failure on either side of the
remote link.
10.1.3
Good practices and the fallacies of remoting
The problems with remoting are well known, and a particularly good description of
them is encapsulated in “Fallacies of Distributed Computing Explained” (Arnon
Rotem-Gal-Oz; see
http://www.rgoarchitects.com/files/fallacies.pdf
). People make
assumptions about distributed systems that are rarely, and often never, true:
The network is reliable
■
Latency is zero
■
Bandwidth is infinite
■
The network is secure
■
Topology doesn't change
■
There's one administrator
■
Transport cost is zero
■
The network is homogeneous
■
You may notice that we used a number of these pieces of information to explain why
remoting isn't used all the time. In general, they indicate a few good practices for
remoting:
Make as few invocations across the remote link as you can.
■
Try to keep parameter data and returned data small.
■
Avoid hardcoding any locations for remote services.
■
Be prepared to handle timeouts, badly behaved clients, and erroneous data.
■
Now that you know a little more about the principles of remoting, it's time for us to
look at the enterprise
OSG
i standard for remoting, the Remote Services Specification.
10.2
The Remote Services Specification
One of the primary aims of the Remote Services Specification is that it should be as
natural as possible to make use of a remote service from within an
OSG
i framework.
One of the big drawbacks in many remoting models is that there are a number of
