Chapter 18
Deploying your Application
In this chapter we'll discuss how to setup your application for distribution
with Sun's Java Web Start technology.
18.1 JMatter Applications Architecture
We already know that JMatter applications rely on a database management
system for storing information, performing queries, and more. The
architecture of JMatter applications is simple and straightforward:
JMatter applications are installed at end-user workstations, and communicate
to the database that resides on the server. This architecture is known
as a two-tier client-server architecture and is quite suitable for
small multi-user applications (roughly up to 100 users).
The dilemma is having to install and maintain JMatter applications
on each client machine. This is where Java Web Start comes to the
rescue.
18.2 Java Web Start
The basic idea behind Java Web Start is to distribute your application
using the world wide web. End users simply visit a web page and click
on a link that triggers the automatic download and installation of
the application to the end-user's computer. Java Web Start is bundled
with every distribution of Java.
It gets even better: each time the end user launches the application,
Java Web Start verifies whether any updates are available and will
automatically download and install the updates prior to launching
the application. So, not only is the distribution of your application
automated but also its maintenance. You can read all about Java Web
Start at http://java.sun.com/products/javawebstart/
In our case, we'll be deploying applications within an intranet or
extranet. Nevertheless, we'll be using web technologies to distribute
and keep our client installations up to date.
18.3 Deploying ContactMgr
JMatter provides an ant target for bundling your application for distribution
via Java Web Start.
We first need to decide what web server to use to deploy our application.
We'll need the machine's host name or ip address, and the port number
(which typically will be 80). Enter these two bits of information
into the file project.properties located in resources/jws/dynamic
Second we need to ensure that the database connection url we specify
in hibernate.properties is not a relative url (such as jdbc:postgresql://localhost/contactmgr);
that url must be valid for all the end-user computers. We also need
to ensure that no firewalls forbid communications traffic between
the end-user machines and the database. Remember, JMatter was designed
for workgroup applications: that is, for multiple users on a Local
Area Network or a Virtual Private Network.
Ok, here's the magic ant target:
-
ant jws-dist
When the target is finished running, it will have produced a .war
file in the dist folder.
Create a directory with the same name as your project inside your
web server's document root directory:
-
sudo mkdir /var/www/ContactMgr
Extract the war file to that directory. This should do the
trick:
-
sudo unzip dist/ContactMgr.war -d /var/www/ContactMgr
We should now be ready to give our application a try. Sit at a client
machine and visit the web page in question (perhaps http://local-server/ContactMgr).
You'll see a page that looks like figure 18.1.
Figure 18.1:
Java Web Start Launch Page
Click on the link and Java Web Start will launch and begin downloading
your application. Before permitting you to proceed, you will be prompted
to accept the certificate used to sign the code (see figure 18.2).
Figure 18.2:
Java Web Start Security Prompt
This requires some explanation. Java Web Start will not run any code
that is not signed with a code certificate. This is not 100% true.
It is possible to customize the Java security policy on every client
machine to allow locally deployed code to run. However this is not
really a viable option as it completely defeats the original purpose
of Java Web Start being a simple and easy way to deploy applications
without having to perform modifications on each client machine.
So the code must be signed. By default JMatter will sign the codebase
anonymously so as to allow the code to run. Java Web Start will prompt
the end-user to allow the the application to launch. This is essentially
the hand-off point. It is the place where you, the developer of the
application, procure a valid code certificate and use it to sign the
code base that you're deploying.
Enough discussion, go ahead and reply Yes to the prompt and
watch the application launch. You can proceed by logging in to the
application and interacting with it as you always have up to now.
That's basically it. That is, anyone in your organization can now
visit the intranet web page for our Contact Manager and with a single
click of the mouse they will have downloaded, installed, and run our
Contact Manager application.
The process of accessing a database by nature is meant to be difficult
as data security is of utmost importance. You need to make sure your
database is configured to accept connections from the network, that
the configuration does not leave any security holes (pass in an MD5
hash of the database user's password for logging in, for example).
If Java Web Start fails during the launch process the first time you
attempt to deploy your application, it is likely due to a connection
timeout attempting to access the database. This would be a good time
to take a moment and review your database documentation and your database
settings.
18.5 Security Options
The PostgresQL database can be configured to communicate with clients
over SSL, providing secure communications between clients and the
database server. This option is an interesting one because it allows
us to consider the possibility of deploying a JMatter application
to a limited number of concurrent users over a wider geographic area.
Also, it's worth mentioning that H2 is a lightweight database that
also supports SSL. In addition it supports encrypting the entire database.
18.6 More About JWS
Figure 18.3 depicts a MacOSX client application
launched via Java Web Start. The database server in this instance
is a PostgresQL cluster running on a nearby Linux machine.
Figure 18.3:
Java Web Start - Launched Application on
a MacOSX Client
The first time the application is launched, Java Web Start will be
downloading and installing an entire application. So the first launch
will be fairly slow; it might take 30 seconds. Subsequent launches
will not require the download (only a quick check for updates against
the server) and consequently will take considerably less time.
The hyperlink on the ContactMgr intranet page is only one way in which
end users can launch their application. Java Web Start can be configured
to place a shortcut for the application directly on the end user's
desktop, for example.
JMatter attempts to make the Java Web Start process as easy and painless
as possible. Let's review what we just did:
- We invoked the ant jws-dist target, and
- extracted the generated .war file to the web server
- Visited the web page and clicked on a link, which triggered Java Web
Start
Anyone who's had to configure Java Web Start the normal way
will certainly appreciate this.