Properly Streaming a Java or JNLP Application (Java client settings in enterprise environment) – part 2

16 08 2012

In a previous post i mentioned JNLP Applets and Application streaming,

Before I dive in to the step by step part of making streamed applications work better when they involve web start applets (JNLP) I first want to provide you with better understanding on how JNLP works because I feel that what I did with Citrix application can be applied to other environments that don’t necessarily feature application streaming like enterprise centralized access for JNLP applications, I also provide some best practice for the beginners and to those looking to consolidate or move those applet to SBC environment or even to just manage them.

Let’s begin,

Ok, so Java as you know is programming language that allows applications to look and feel the same on different platforms without much dependencies all you need is have the Java Runtime Environment (JRE for short) installed,

JRE can be installed in a couple of modes, a “Static” or a “Patch In Place” mode which you can read about here

“Static” – enables you to install a version of let’s say 1.6.20 if some line of business application demands only that version (example verizon applet) after you install the static version, that version will remain present even if you or your users install JRE 1.6.30 so if they do then in theory nothing broke and at max you will need to set some parameter for the application to load with that specific JRE version, it’s not giving you total control which is good for desktops.

“Patch In Place” – regular known configuration, new update replace old version files, not managed to say the least.

Now In a XenApp environment it’s a whole different story, if you have multiple applications who are each dependent on a specific version of JRE you are kinda stuck with having “Silos” of servers for each app, that’s can cause a major management overheadache as i like to call it, so in XenApp i would recommend you employ one the application virtualization enables out there, XenApp application is good and free if you have the enterprise licensing, small learning curve and a collection of utilities and support from Citrix, This does not apply to every environment, it applies mostly if you or the organization have interest in keeping as few servers as possible.

On to the next consideration, the type of java application your’e dealing with,

i like to divide in to 4 types:

Server side JVM – the whole application is compiled on the JVM server (example websphere application server) , requires a client to have the right version

AJAX – uses java script, rather transparent to use, does not need client

Java Application – uses JAR file which are saved to cache during runtime, “thin” client

Java Applet – “Thick” client, a JNLP file is downloaded to local machine cache, desktop shortcuts and other integration with the Client OS are available.

Java Applets are run by component in the JRE called “Java Web Start” (javaws), this component has really nice features that when you know about them you understand that’s it’s quite a managed client.

JAVAWS Caching –

i want to present two scenarios related to Citrix and Endpoints Administrators and examine how java caching configuration will be of service:

1) A line of business JNLP application has a requirement to run from a desktop environment (might be that you don’t have SBC environment in place, or it’s not compatible with another terminal operated line of business JRE requirement).
that line of business operates for years and being cached to each user’s profile when first accessed, all of a sudden (as if you didn’t predict it would happen) the vendor decided to upgrade and asks you to clear any previous cache of the application,
if you had a procedure in place to have it run from the desktop javaws’ system cache, there would be a whole lot you could do without requiring the user to be logged in, heck, you could even delete the cache, upgrade and all in an hour’s work with a product like SCCM.

2) in this scenario you have a XenApp environment and you have a application virtualization solution in place,
the way these solutions work is creating a sandboxed environment that contains all the dependencies (exlcluding kernel drivers except for a few products) to have them work you need to first “Sequence” or “Profile” the application, in that process you install the dependencies and configure them and finally package them, next all that the client does is re-construct the dependencies and run the application, no need to install anything,
so you have your JRE all configured by installing JRE and running IE,
That won’t work for JNLP applications, you will have to use the system cache otherwise all the caching will be done everytime a user opens the application, and with application like PSNext or WebCenter it’s a big no no since the loading time will be tremendous for first timers (hint: the dev. who want to see if your solution for hosting the jnlp applet is really better)

On the next post i’ll go into the step by step of actually configuring this with application virtualization tools and without them.

for more info on java from a system management perspective see these links:




2 responses

25 06 2013

Did you ever finish part 3 of this article…very interested in what you did here

25 06 2013
LeITchronicle Admin

Hi GB, no, I will try to make it available soon.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: