Java Reference
In-Depth Information
downloaded by our
BankClientLoader
,of course) will allow for easy startup deployment mod-
ifications. When we want to modify the CHECK command, we just download the new class
that will implement the new startup deployment code. Unfortunately, we don't have the space
to present this and other enhancements to the code presented here.
Another shortcoming in our design (already mentioned before) is regarding the GET command
used by the
getRemoteFile
method beginning at line 163 in Listing 6.2. To download a file
from the server (both for missing classes and resources), the
ApplicationHelper
uses the GET
command. Given that the
ApplicationHelper
is not updateable anymore once it is installed on
the client, we obtain that the GET command is hard-wired in the protocol. When we want to
modify the GET command in our communication protocol in the future, we are forced to cre-
ate another command, say GET2. If we modify the existing GET command, our application
helpers installed on the clients won't work anymore. In this example, we must keep working
legacy code that uses the GET command, so we have no choice. Anyway, in other situations
this could reveal itself to be a problem in the long-term software maintenance.
This problem originated from the fact that we violated the design principle of keeping sepa-
rated the business from the deployment layer. The GET command is a business command we
used as for deployment.
Summary
Abstracting from the code reuse problem that motivated this deployment solution at first, there
are several general aspects to point out here. For instance, all JNLP client implementations (as
Java Web Start) could be thought of as a more sophisticated version of our architecture, in
which application helpers parse special XML files in order to provide a wider range of deploy-
ment services.
The most interesting (and reusable) aspects of this solution are as follows:
• The classloader mechanism for implementing a full-fledged, 100% Java application
helper.
• The overall software architecture: An application helper that uses a cache mechanism for
providing deployment services to business classes. Clearly, a real-world application
helper will employ several possibly optimized caches, other auxiliary data structures, etc.
• The software design process for reorganizing more rationally the existing code, and gen-
erally to better think classes relatively to their deployment.
•A mechanism for ensuring full compatibility of new deployment features with older soft-
ware.
While other details such as the communication mechanism, the class and resources loading
rules, and the cache implementation are all to be intended as demonstrative and limited to the
current case only.
