Nirvana Deployment Guide - Browser / Applet Deployment

Introduction

Nirvana client applications can run within stand alone applications as well as within Java applets loaded via a web browser such as MS Internet Explorer, Netscape, Firefox Mozilla etc.

The Nirvana client apis are compliant both with the Sun Plug-in as well as any browser JVM such as Mircrosoft's 1.14 Java implentation. This ensures that for your client application's deployment perspective, there are very few considerations with regard to the target client architecture.

Applet Sandbox / Host Machine Limitation

Applets run within a client's browser, and are subject to strict security limitations as defined by the Applet Model. These limitations need to be considered when deploying applets. One such limitaion is that the applet is only allowed to communicate with the host machine from which the applet was downloaded. This restricts the applet to only being permitted to make connections to the applet host machine. This has a number of implications for an applet that uses Nirvana's APIs.

Nirvana's APIs communicate with a Realm Server (or potentially multiple servers in a cluster). This limitation means that the applet source host must be the same hostname as each Nirvana Realm in use by the applet. If the applet is served from a webserver, such as Apache, and it is assumed the communication protocol required for Nirvana communication is nhp/nhps (http/https). The usual ports used by webservers running http and https are 80 and 443 respecitively. Since the web server uses these ports and the realm servers need to run on the same machine with these ports there is obviously a problem since these ports are in use.

However, Nirvana provides 2 different methods for ensuring this is not a problem. The first is Nirvana's ability to act as a web server through its file plugin. Running a file plugin on an nhp or nhps interface enables the realm server to deliver the applet to the client browser, this removing the need for the webserver and of course freeing up the ports for use by the realm server interfaces.

The second method can be used when the webserver is apache. We can provide an apache module that acts similarly to mod.proxy for apache. This apache module called mod.Nirvana allows the web server to proxy all requests for a specific URL to another host. This host can be the realm server running on any other port on the same machine or any other machine, and hence once again fixes this issue.

Another way to circumvent this restriction is to digitally sign the applet and thus allowing the applet to communicate with any host.