Web services play a central part of all SaaSGrid applications, including those that take advantage of SaaSGrid’s native Silverlight 3 Support. There are some things to be aware of when developing, and more importantly, configuring your services so that Silverlight can talk to them. This is because the WCF client stack in Silverlight 3 is somewhat limited compared to the more complete .NET WCF stack. This article will explain how to appropriately set up your WCF services so that your SaaSGrid-based Silverlight 3 proxies can contact your services.
There are three fundamental requirements to be aware of when configuring your WCF services:
Note that the first two requirements are not imposed by SaaSGrid. They are necessary to permit Silverlight to contact your WCF services. The final requirement adds SaaSGrid “awareness” to your service. Each of these requirements is described further below.
Use the basicHttp binding instead of (or in addition to) the netTcp binding.
Silverlight 3 simply does not support the netTcp binding. Therefore you should use the basicHttp binding so Silverlight can talk to your service when developing locally and using Silverlight. Note that SaaSGrid supports both the netTcp and basicHttp bindings (although netTcp is the default on SaaSGrid and encouraged for a variety of reasons).
When your service is ultimately deployed on SaaSGrid, the service will be deployed onto the cloud using both bindings, and SaaSGrid’s routing mechanism will forward requests made by your Silverlight application from the web server to the running instance. (For information on correctly configuring your Silverlight application to contact the service, refer to the “Silverlight” section of the Developing on SaaSGrid guide.)
The following is a sample configuration file of a service that uses the basicHttp binding, which will be enhanced as the additional requirements are covered in this document:
<system.serviceModel>
<services>
<service name="Service.Service">
<endpoint address="http://localhost:4001/Service"
binding="basicHttpBinding"
bindingConfiguration="defaultBasicHttpBinding"
contract="Service.IService"/>
</service>
</services>
<bindings>
<basicHttpBinding>
<binding name="defaultBasicHttpBinding">
<security mode="None"/>
</binding>
</basicHttpBinding>
</bindings> . . .
Enhance your service to serve the clientaccesspolicy.xml file to fulfill Silverlight 3 security requirements.
Silverlight, before dispatching any service calls to a running service, will request the file called clientaccesspolicy.xml from the root of the service (e.g.: http://localhost:4001/clientaccesspolicy.xml). This is a requirement that Silverlight 3 plug-in imposes for security purposes and is not SaaSGrid specific. When developing locally you must enhance your service to serve this file. When the service is running on SaaSGrid, our routing system will automatically serve this file.
To enhance your service to fulfill this client request, create a new endpoint using the webHttp binding and create a new service contract containing a single operation that responds to the request for the clientaccesspolicy.xml file. This is best described with an example, building upon that in the previous step.
First, add the endpoint and behavior in the service configuration file:
<endpoint address="http://localhost:4001"
binding="webHttpBinding"
behaviorConfiguration="webHttpBehavior"
contract="Service.IClientAccessPolicy" />
</bindings>
<behaviors>
<endpointBehaviors>
<behavior name="webHttpBehavior">
<webHttp />
</behavior>
</endpointBehaviors>
</behaviors> . . .
Then, add a new service contract with the operation that will respond to clientaccesspolicy.xml:
[ServiceContract]
public interface IClientAccessPolicy
{
[OperationContract, WebGet(UriTemplate = "/clientaccesspolicy.xml")]
Stream GetClientAccessPolicy();
}
Finally, implement this service contract.
public class Service : IService, IClientAccessPolicy
. . .
public Stream GetClientAccessPolicy()
const string result =
@"<?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>";
if (WebOperationContext.Current != null)
WebOperationContext.Current.OutgoingResponse.ContentType =
"application/xml";
return new MemoryStream(Encoding.UTF8.GetBytes(result));
After following these steps, the fundamental requirements for a Silverlight application to communicate with the WCF Service have been met. However, SaaSGrid requires some additional endpoint configuration, described below.
Attach SaaSGrid’s ContextEndpointBehaviorExtension to all of your service endpoints (except that which serves your clientaccesspolicy.xml).
SaaSGrid attaches contextual information when the client makes service calls, which the service later reads. This allows an otherwise stateless service to know which SaaSGrid-based user is making the service call so that SaaSGrid’s subscription and security model can be applied.
This is achieved by applying the ContextEndpointBehaviorExtension to all of the endpoints that respond to service calls. As expected, the endpoint handling the call to the clientaccesspolicy.xml file must be excluded as this call will not include the SaaSGrid contextual information.
Note that for non-Silverlight applications, this behavior can be configured at the service level, and the Visual Studio SDK Template applies the configuration this way. [Note that this will be changing over the next few weeks.]
Below is the abbreviated final markup of the service configuration to use the endpoint behavior:
behaviorConfiguration="ApprendaEndpointBehavior"
<behavior name="ApprendaEndpointBehavior">
<ContextBehavior />
</behaviors>
<extensions>
<behaviorExtensions>
<add name="ContextBehavior"
type="Apprenda.SaaSGrid.API.Local.`
ContextEndpointBehaviorExtension, SaaSGrid.API.Local,`
Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
</behaviorExtensions>
</extensions>
</system.serviceModel>
Conclusion
Upon following these requirements, your service should now be equipped to work with both Silverlight and SaaSGrid. Our Taskr with Silverlight sample provides an implementation of the concepts presented in this posting. If you encounter any issues or have any questions, don’t hesitate to post in our developer forums.