Server-Side Deployment Support - Java Deployment with JNLP and WebStart - page 347

For example, a basic server can only support this kind of request from a JNLP client:

http://www.mybasicserver.com/downloadpath/file.jar

While a full JNLP server can reply to more sophisticated requests like the following:

http://www.myjnlpserver.com/servletpath/file.jar?version-
➥ id=3.1.2*+3.4*&os=”windows”&current-version-id=2.8.2

Note that posing these kind of requests to a basic Web server will generally cause an error on
the JNLP client. This is not a problem anyway, as long as your JNLP files (that ultimately trig-
ger client requests) are written for and tested on the server you are going to use.

12

Deploying Resources to the Server
In this section, we will see how to prepare the server environment for enabling full support of
the JNLP protocol.

We will refer to a servlet implementation of the JNLP server as the one provided by Sun (that
is intended only for development) or the Juniper project implementation.

Practically, those interested in providing full JNLP support should install one of the servlet-
based solutions available to developers. See the Sun Web Start page for some further details.

As for servlet deployment, there are some practical notes in Chapter 5 as well.

Server-Side Resource Management
In the preceding chapters, we concentrated on the client-side of the protocol, assuming basic
support on the server. Files are treated like passive resources that are sent back to the request-
ing client, like the usual behavior of a static Web server.

In this scenario, each file is uniquely identified by its URL path. The JNLP client (or simply
client, for brevity) may request files specifying some given attributes value as well. The attrib-
utes JNLP supports are the following:

• Ve r sions . The version of the given resource. Versions are encoded with strings, as we
will see later.
• Supported OS . The operating systems that the given resource is designed to run on.
• Supported Architectures . Beyond the OS, the underlying hardware architecture also
matters sometimes.
• Locales . The job of localizing resources (that is, dividing them in groups depending on
the supported languages) can be left to the protocol, to avoid huge all-can-do JAR files
that support dozens of languages. The benefits are twofold: reduced download bandwidth
and easier management during the development lifecycle.