In a perfect world you would have access to all of the services your Silverlight application will call. Unfortunately, we don't live in a perfect world so you will almost certainly run into situations where your application will need to call a service which does not have a cross domain or client access policy file deployed with it. No worries, you have a couple of options to work around the issue.
Silverlight Web service support and policy files
With the release of Silverlight 2 and now version 3 you are provided with rich Web service support. Silverlight provides support to access many types of web services including POX, REST, and SOAP services. Just as you would for a WPF or ASP.NET application you have the option of adding service references to your Silverlight projects and calling services through the generated proxy. You can also utilize the WebClient and HttpWebRequest objects to manually call services.
No matter what method you choose to reference and call Web services from Silverlight you are required to have a cross domain policy file at the root of your destination service domain. This policy file is required to verify that your specific Silverlight application has the right to call that service. Silverlight supports the Flash utilized CrossDomainPolicy files as well as its own ClientAccessPolicy file format. The details of these files are outside of the scope of this tip; the important thing to note is that services called across domains from Silverlight must have one or the other present.
90% of the time you will have access to services your Silverlight application call and will be able to deploy policy files for those services. For the other 10% of the time you have a couple of options.
Calling Web services through service proxies
The easiest solution to calling cross domain Web services which don't have a policy file is to use something called a man-in-the-middle proxy. This is simply a Web service that you create to act as a proxy between your Silverlight application and the Web services it doesn't have access to. In this scenario you will create the service proxy on the same domain as your Silverlight application and it will be the service your Silverlight application communicates with. Your proxy service will then, in turn, communicate with the destination service and forward any responses back appropriately.
This is a pretty straight forward work around and there is really only one drawback. You now have both your Silverlight application and Web service proxy to maintain. Any time the destination service changes both your Silverlight application and Web service proxy will have to be updated accordingly. One way around this would be to generate the proxy service code using a utility you write or an application such as CodeSmith. You will still have to apply updates to your Silverlight application, but the proxy can just be re-generated.
Calling Web services utilizing JavaScript
A second solution is to access the destination service via JavaScript. Silverlight provides rich JavaScript interop functionality, through the HTML Bridge, which allows you to call JavaScript methods from your managed code and also allows JavaScript to call back into your managed code. With this support you will create JavaScript methods responsible for calling the destination service. You can do this either manually using the XMLHttpRequest object or by utilizing Web service support in a JavaScript library such as Microsoft's ASP.NET Ajax or JQuery.
This work around is nice in that you don't have any service calling code duplicated as with the first solution. That said, you do have the drawback of having to deal with unmanaged JavaScript and all the coding and debugging issues that come along with it. The best mitigation strategy is to code only the actual service call processing code in JavaScript leaving the request creation and response parsing logic in managed code.
Conclusion
Using the techniques described in this tip you will be able to call any Web service from Silverlight, even one without a cross domain policy file.
About the author
Steven Porter is a Senior Consultant and Project Manager for Wintellect, a consulting/debugging yand training firm founded by industry experts Jeff Prosise, Jeffrey Richter, and John Robbins. He specializes in technologies such as ASP.NET, ASP.NET Ajax, Silverlight, and WPF. Steve is a Microsoft MVP in Client Application Development and a frequent speaker at events such as user groups and code camps on topics ranging from Silverlight and WPF to Windows Communications Foundation.
