Posted by gonzo
on October 1, 2004 at 5:23 PM PDT
PermaAlpha - the ability to readily deploy any build of any app.
WebStart is an amazing deployment vehicle. Following is a bit of detail describing JXTA's use of JNLP (Java Network Launch Protocol) and the process it enables.
Firstly, a bit about the process. JXTA builds of the following projects occur nightly in addition to quarterly releases :
Building JXTA 1 2 3 describes the techniques behind the overall build process used to generate the JXTA Download site.
As of late, the JNLP builds have been included in both the recent release and the nightlies. As such, trying out WebStart enabled JXTA applications is as trivial as navigating to the relevant build and selecting the associated JNLP link. For example:
This very same process has been applied to the nightly builds, so that not only can the latest and greatest binaries, source and documentation be readily obtained one can also run, via WebStart, the latest build, every night. Thusly PermaAlpha. For example, in order to run the latest build the only change to the above process is the base URL:
That's it. It is trivial for anyone to try out both the latest milestone build in addition to taking a peek at new features that are to be included a future release. For the developer, this provides the opportunity to readily deploy builds, be it milestones or alphas, and solicit instant feedback. It really doesn't get any better then that. Real feedback real time for any build.
But the goodness doesn't stop there. Leveraging the afore mentioned JNLP distributions for your own work is readily attainable. To illustrate how to build upon this infrastructure I'll lay out the project principals, the constituents within, the interdependencies and the MyJXTA JNLP file.
To start with, there are two (that I am aware of) types of JNLP files: applications and components. JNLP applications include application information, such as a main class, whereas JNLP components include component information. Beyond those differences the files are largely similiar for any given application.
For purposes of consistency the JXTA nightly release will be used as the reference noting that the same information corresponds directly to a release build.
In order to establish some context the following table lists the JXTA projects, thier constituents and the projects they, in turn, depend upon.
|content management system
cmu us kevin
From this matrix one can readily derive the corresponding JNLP file composition and inter-relationships. Within JXTA we use the naming notiation of -ext.jnlp to signify a JNLP component.
Now, the real value of this model and the heart of this very blog entry, is that one can readily change any single JNLP resource, for example a low-level jar file, and re-launch the application in order to test the outcome. Further, the site deployer, in this case JXTA proper, can change the JNLP constituents over time shielding the higher-lvel apps from the changes over time. This is precisely the case with MyJXTA and in looking at the details of how it relates to the other JXTA principals.
Firstly, MyJXTA leverages several 3rd party applications to great advantage. Accordingly, these JNLP entries are managed by the MyJXTA team and thusly can vary over time with little impact. MyJXTA references Platform Extension as a dependency, in addition to Shell and CMS. Platform Extension, in turn references Platform in the same manner as Shell and CMS. From this indirect relationship MyJXTA is shielded from structural changes that may occur within the Platform Extension deployment and it's dependencies in turn. As such, readily deploying a application in aggregate via JNLP scales nicely.
Following is the MyJXTA JNLP descriptor noting that it can be readily used as a template for a similiar JXTA application:
<?xml version="1.0" encoding="utf-8"?>
<description>MyJXTA: chat, share ... change the world</description>
<description kind="short">MyJXTA: chat, share and more</description>
<icon href="myjxta.gif" width="10" height="16"/>
<menu submenu="JXTA" online="true"/>
<jar href="lib/myjxta.jar" main="true" download="eager"/>
The bold sections above can be inlined as is by any JXTA enabled applications greatly easing the overall deployment process.
It should be noted that in preparing this entry I noticed a bit of JNLP normalization that
we should consider. Although it is tempting to state that "I'll leave it as an exercise for the interested student to ..." I'll simply add that the platform-ext.jnlp reference above is redundant in that Platform Extension, Shell and CMS all include that dependency natively. That said, WebStart nicely smooths out the dependency maps at runtime for the end user. I think a similiar relationships occurs between the Platform and Platform Extension JNLP files that we should consider as well. That said, JXTA is an open source project so perhaps others have ideas and/or interest in lending a hand in building out the secure and pervassive network vision that is JXTA. that has since been addressed.
Java == platform independence
XML == application independence
JXTA == network independence
Secure End-to-End Computing
in my ears : Nine Inch Nails/Things Falling Apart/Metal