Java Reference
In-Depth Information
•Clients can upload textual data on the central server using the GET command.
• The POST command lets clients download files from the central server.
• The QUIT command allows for a graceful session shutdown.
6
Our application is inherently IO-bounded and, in this version, the server connection was
always assumed to be available (refer to Listing 6.1) for the transactions to be successfully
accomplished.
We won't show here the server code because it is very similar to the code of the server imple-
mentation we will discuss in Listing 6.4.
Our Solution
Given the strict requirements described previously, we are forced to an ad-hoc solution. We
will build our own Application Helper (refer to Chapter 2, “An Abstract Model for
Deployment”) that will take care of all the software deployment, taking advantage of the J2SE
class loading mechanism.
This solution has a high first-time activation cost because we need to redeploy the new soft-
ware to all the clients. This is needed only once, anyway. The following updates will be han-
dled by our application helper in a transparent way.
Some Design Issues
Strictly speaking, the J2SE class loader mechanism adds a new level of indirection to our
applications. When specifying our own class loader, we can control how classes are loaded into
the JVM and where to find the resources they access. It is much like a Java program being able
to load and execute another Java program.
It is not a surprise that customizing the class loader is a commonly used technique for imple-
menting deployment services on the J2SE platform.
Often, when porting existing code to new architectures, developers realize that some new
arrangements would be required. When creating deployment facilities for our software, we are
just adding a new group of software services to the existing code. Often, making this distinc-
tion explicit is the wisest architectural choice.
This is the case in our code, too. Instead of using the existing code for implementing the
deployment services (for example, taking advantage of the existing GET command), we will
follow the design principle of total separation between deployment services and other busi-
ness-oriented code. This approach could duplicate code at first, but it pays off in the
medium-long run in terms of flexibility and design coherence.
