Universal Messaging 10.5 | Concepts | Deployment | Client | Browser / Applet Deployment
 
Browser / Applet Deployment
Introduction
Universal Messaging client applications can run within stand alone applications as well as within Java applets loaded via a web browser such as Google Chrome, Mozilla Firefox, Microsoft Internet Explorer and Microsoft Edge.
The Universal Messaging client APIs can be used with most Java Plugin versions.
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 limitation 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 Universal Messaging's APIs.
Universal Messaging'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 Universal Messaging Realm in use by the applet. If the applet is served from a web server, such as Apache, and it is assumed the communication protocol required for Universal Messaging communication is nhp/nhps (http/https). The usual ports used by web servers running http and https are 80 and 443 respectively. 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, Universal Messaging provides 2 different methods for ensuring this is not a problem. The first is Universal Messaging'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 web server and of course freeing up the ports for use by the realm server interfaces.
The second method can be used when the web server is apache. We can provide an apache module that acts similarly to mod.proxy for apache. This apache module called mod.Universal Messaging 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.