Chapter 19
Deployment, Take II: The Application Browser
Deploying JMatter applications with Java WebStart works well enough.
It's certainly what people term the fat client model, where
the client application is quite sizable, in the order of 20 Megabytes,
primarily due to the large number of dependent libraries required
to support the application.
The web model on the other hand is seen as a more lightweight approach,
and termed the thin client model.
In a manner directly analogous to the web, JMatter now supports a
thin client model for deploying your applications, thereby
deriving the same set of benefits typically associated with web:
- Smaller downloads
- Dynamic application loading
- No installation required (just visit a URL)
Here is how it works. JMatter comes equipped with an application named
the Application Browser. You will find it in the base directory
of the JMatter distribution. This application consists of a single
model object: the Application Bookmark. Roughly speaking, this
application is to JMatter applications what the Firefox web browser
is to web applications: it's an application that allows you to load
applications by specifying or entering a URL.
The Application Browser can be packaged and deployed using the traditional
Java WebStart mechanism, or perhaps through the more traditional mechanism
of using an automated installer. By virtue of being implemented entirely
in Java, this application is by definition cross-platform. It's worthwhile
noting that the JMatter application browser is itself nothing but
a standard JMatter application with a very simple model comprising
a single entity: the Bookmark.
19.1 How it works, by example
Allow me to illustrate how this deployment mechanism works by example:
let's deploy the Sympster application. Here are the steps we need
to follow:
- Package the application
- Copy the packaged application to a web server so it can be http-loaded
- Launch the application browser
- Specify the url for the application and launch the application
For the first task, you will find a new JMatter ant target named jar-model
that will produce the packaged artifact. The output of this target
is the file dist/Sympster.jar which consists strictly of the
compiled object model and supporting classes (if any), the application
resources and configuration files (images, class-list.json, hibernate
mapping files, database connection setings, and spring configuration
files).
We can now upload the artifact to a web server, say for example, to
the jmatter.org web site perhaps at the url: http://jmatter.org/demo-apps/Sympster.jar
We now launch the application browser.
Figure 19.1: The JMatter Application Browser
In Figure 19.1, we see that I've defined an application
bookmark for the Sympster demo application that I've deployed to jmatter.org.
I can now click on the Launch button to launch the application.
The jar file is downloaded, and class-loaded into the client application's
virtual machine. The application configuration is read and the application
is loaded. Its splash screen appears, and we are finally presented
with a login dialog. Upon logging in, we see the Sympster application's
class bar show up on the left hand side and we're ready to start using
our application: perhaps defining new talks, creating a new session
schedule for an upcoming symposium, etc..
When we're finished with our Sympster application session, we can
either quit the application, or unload it (from the menu: File
-> Unload Application). The Application Browser re-appears, and we
can choose to launch an entirely different application from a different
URL.
The application model remains two-tier, with the application talking
directly to its back-end database. But it is worthwhile at this time
to examine the benefits of this method of deployment:
- We have turned a fat client into a thin client
- The size of our download has shrunk from 20MB to 80KB (it's worth
stressing that many web pages today are larger than 80KB)
- No installation of Sympster was necessary
- Developers are free to work on enhanced versions of the application,
drop a new copy on the web server, and thereby upgrading the application,
in a manner that is transparent to clients (end users)
19.2 Dealing with dependencies
The MyTunes demo application is a good example of an application that
has dependencies on third party libraries that are not bundled with
the Application Browser. How can we deploy MyTunes along with these
necessary dependencies?
The answer turns out to be very simple. All that is necessary is to
properly cite the dependencies in the jar file's manifest. Here is
MyTune's ant target jar-model:
-
<target name="jar-model" description="jar just the model"
depends="clean,genhbm">
<jar file="${model-jar.file}">
<manifest>
<attribute name="Created-By" value="jMatter" />
<attribute name="Main-Class" value="${main.class}" />
<attribute name="Class-Path" value="JID3.jar jl1.0.jar" />
</manifest>
<fileset dir="${build.classes.dir}" includes="**/*" />
</jar>
</target>
The interesting part here is how we've added the two libraries JID3.jar
and jl1.0.jar (responsible for playing mp3's) using the jar
manifest's Class-Path attribute. All we do next is make sure to put
these libraries alongside MyTunes.jar on our web server. The
rest is transparent: the associated jar files are fetched alongside
the application. In this case our application is 300KB in size, counting
the dependencies. Not bad for a music player.
19.3 Looking Ahead
We're thinking about further enhancing the application browser to
allow multiple applications to be loaded in separate tabs, in a manner
similar to the way that web browsers today feature tabbed-browsing.
We're also beginning to contemplate developing a way to run JMatter
applications using a three-tier model: by splitting the application
logic between client and application server.