Java Reference
In-Depth Information
solution is to define methods on the client callable by the server so the server
can “push” the new data to the client when it has new data available. The client
and server roles are reversed temporarily while what we have been calling the
server acts as a client by making a call to the real client, which plays the role
of a server for that call. In this technique, the real server is said to be “calling
back” to the client, and the technique is generally referred to as a “callback”
scheme. Callbacks are a good technique in some situations, and they reduce net-
work overhead by eliminating unnecessary polling calls. Unfortunately, callbacks
seldom work through firewalls. So, if the server is designed to be called from
outside its internal network, then using callbacks is generally not a successful
approach.
We have left out many details in the description above. What we have provided
is a general outline of how to produce a distributed object application, and we've
learned enough UML notation to describe the behavior of the server. While fairly
complex, all of the above should become clear when we produce actual working
code in Chapter 20 after we've covered a few more theoretical issues. In the gen-
eral description above, the main thing missing is any mention of client behavior,
the subject of the next chapter.
Before proceeding to the client though, let's finish the discussion of the UML
class diagram. Notice that the
Server
implements
ServerInterface
,as
shown by the dashed line and hollow arrowhead. Since an implementation must
provide concrete methods for the methods defined in the interface, we show
Server
with the same three public methods that appear in
ServerInter-
face
.Wealso indicate two attributes on
Server
, marked with a
“-
„
sign to
indicate private access. One is a reference to
ServerFactory
. This reference
can be used by
Server
to communicate with its factory. An example of such
use is for diagnostic logging in which the factory keeps a log of server behav-
ior. Another use is for synchronization with respect to the factory object for
short-running pieces of native code that are not inherently thread-safe. By syn-
chronizing with respect to the singleton factory, we can ensure that no two clients
access a non-thread-safe native method at the same time. As long as the non-
thread-safe native methods are not time consuming, this simple solution provides
thread safety with very little effort. Obviously this solution is not adequate for
long-running or frequently accessed native methods because too much thread
blocking would occur. The other private
Server
attribute is a copy of the ID
that was received when the factory instantiated the server during sequence 2.1 in
Figure 16.4.
16.7 Web Course materials
The Chapter 16 in the Web Course provides further discussion and resources
regarding distributed computing for technical applications, client/server design,
and UML.
Search WWH ::
Custom Search