Universal Messaging Silverlight Deployment
We provide a separate 'Tradespace Demos' download that contains a fully working Silverlight application called Tradespace. When you follow the instructions, you are able to load the Silverlight Tradespace demo application from your Universal Messaging realm.
The setup of the demos performs the following actions:
Adds an http interface on port 8080
Adds a file plugin to your this interface (this enables the Universal Messaging server to act as a web server and serve content to browsers)
Creates the required channels in the realm used by the Tradespace demos.
Running through the demos setup is the simplest way to get started with Universal Messaging and deployment of a Silverlight application - in this case the Tradespace Silverlight demo. You can of course go through the individual steps described above yourself and deploy your own Silverlight application.
Channel ACLs
When creating a Silverlight application, it is worth remembering to correctly set the ACLs for both the realm(s) and channel(s) used, to ensure that the application is able to access the Universal Messaging server. This can easily be performed using the Enterprise Manager.
Silverlight's Client Access Policy File
When deploying a Silverlight application on a different host to the Universal Messaging server, Silverlight requires the use of a client access policy file to validate that the connection is permitted. For example :
you deploy your Silverlight application from webhost1.yourdomain.com:80
your Universal Messaging server is located on nirvanahost1.yourdomain.com:80
When Silverlight detects a connect attempt outside of the host from which the application was downloaded, it makes a request for the policy file from the host you are making the connection to. When using an nhp (HTTP) or nhps (HTTPS) RNAME to connect to the Universal Messaging realm, Silverlight makes a GET request for a clientaccesspolicy.xml file from the root of the web server (in this case, the file plugin running on the Universal Messaging server HTTP or HTTPS interface). If no clientaccesspolicy.xml is found, it then makes a second GET for a crossdomain.xml file, again from the root of the file plugin. The crossdomain.xml file is also used by flex clients for the same reason.
An example of a
clientaccesspolicy.xml file for Silverlight clients is shown below. This example should not be used for anything other than testing purposes, as it essentially allows open access to and from all domains. For more information on cross domain access with Silverlight, and configuring the
clientaccesspolicy.xml file, see the
Microsoft MSDN guide.
<?xml version="1.0" encoding="utf-8"?>
<access-policy>
<cross-domain-access>
<policy>
<allow-from http-request-headers="*">
<domain uri="*"/>
</allow-from>
<grant-to>
<resource path="/" include-subpaths="true"/>
</grant-to>
</policy>
</cross-domain-access>
</access-policy>
