WCF - SeeSharp

CrossDomain Problem with Silverlight Applications

HEskandari — Tue, 18 May 2010 00:00:00 GMT

When creating Line of Business (LoB) applications with Silverlight, the only choice to get the data to the application is through webservices. People having their Silverlight application hosted on the same webserver as the service have almost no problem, but things get interesting when service is not hosted on the same machine as the application, and it gets hairy when you self-host a WCF service. Let's see how it is done in each scenario.

Background
Generally, RIA applications including Adobe AIR or Microsoft Silverlight due to certain considerations, won't let your application use a remote service, if the service does not allow you to connect explicitly. This is done through a Client Policy file that should be available at the root of the webserver running the service. The client policy file, which is an XML document, grants the client permission to connect to the service. For example, if your webservice is running on a domain, e.g.

http://www.hightech.ir/OrderingService

your client policy file should be located at the root of the same domain, for example for a Silverlight application using the above service, it'd be located at:

http://www.hightech.ir/clientaccesspolicy.xml

For more information about this file and content of the file, you can check out the specification here.

Web hosted Web Service
This is the easiest of them all. Since your webservice is hosted in a webserver, you just need to create a xml file and place it at the root of your webserver. To make sure it works, open the address to the Client Policy file in your web browser. This works painlessly for WCF services using basic HTTP binding that are hosted on IIS.

JBoss hosted JAX-WS Service
Since JAX-WS services comply with SOAP standards, thse services are considered regular http webservices, so if you have read my series describing how you can use JBoss to host your services and create a Silverlight rich client to consume those services, you already have figured out the basics.

But JBoss is an application server...How can I add a xml file to the root of the "application server"? JBoss comes with a built-in apache webserver and there is a special folder in your JBoss installation that is considered the webserver root. So just like IIS where you copied your file to the root of the webserver, copy the client policy file into:

%JBoss Folder%/server/%installation%/deploy/jboss-web.deployer/ROOT.war/

The above path translates into this on my machine:

C:\Java\JBoss-4.2.3.GA\server\default\deploy\jboss-web.deployer\ROOT.war\

Self-Hosted WCF Service
It gets pretty interesting when you're hosting the WCF services yourself. When it comes to hosting the WCF service, it is possible to use a Console Application (or much better a Windows Service) to host the services for you. This way, you just have a Windows service or an application, which both are way different than a webserver. Where should you place the client policy file now?

Note: There are many benefits that comes free when hosting the WCF service in IIS, so self-host the services in case you have a good reason to.

To return the client policy file when a request comes through you need to create a special Service Host that does just that. It is mandatory to use WebHttpBinding to make this work. Then you can create a WCF service that returns the content of the client policy. Here's an example:

[ServiceContract(Namespace = ServiceSettings.Config.GeneralNamespace)]
public interface ICrossDomainService
{
    [OperationContract]
    [WebGet(UriTemplate = "/clientaccesspolicy.xml")]
    Stream ProvidePolicyFile();
}

public class CrossDomainService : ICrossDomainService
{
    public Stream ProvidePolicyFile()
    {
        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>";
        return ConvertToStream(result);
    }

    private Stream ConvertToStream(string result)
    {
        WebOperationContext.Current.OutgoingResponse.ContentType = "application/xml";
        return new MemoryStream(Encoding.UTF8.GetBytes(result));
    }
}

Did you notice the extra WebGet attribute beside the ServiceContract? Specifying the UriTemplate will do the trick and will send the hard-coded content of the client policy when a request at specified Uri comes through.

Note: Make sure you don't mix up these two bindings. For WCF service to be consumable in Silverlight client, you need to have a BasicHttpBinding but for the client access content binding should be WebHttpBinding.

Silverlight + RESTful POX

HEskandari — Wed, 28 Jan 2009 15:45:00 GMT

I'm working on a small project for a Swedish company. They need their application be available via web, so it's time to put that Silverlight knowledge at work. I decided to use Silverlight for UI technology and have a REST service layer to provide the required data. After all Silverlight and REST services should have no problem. Silverlight experience was great. You have LINQ at your disposal to process the REST results and although the set of available commands in Silverlight is less than WPF, but this makes it is easier to learn and work with at the same time. There was a couple of gatchas along the way, so I'm writing this as a note-to-self.

Service Contract vs. Object Model

The domain model is very simple and consist of a couple of entities, so what REST Services expose as data contracts are more or less the same as what I use in application layer. Silverlight's class library is not the same as a normal class library so I can not reuse the domain model available in my Silverlight library. This will lead to two set of object models. One for the domain model and the other for the service layer as data contracts. This separation or concern is a good idea, but for this small application it is overkill, but there's nothing I can do with it. With the help of LINQ2XML the best choice for exposing the contract model is POX (Plain old XML) so result of our services would be in XML parse by LINQ and converted to our domain model.

Unit Testing

Also because of different class library outputs, you can not use unit testing frameworks the way you usually do. This means you can not use xUnit, nUnit, etc. Hopefully there's a test harness to allow both UI and API level testing when developing Silverlight and it works just like MSTest does. Download the binary files here and read this to know how to add templates to your VS.NET to easily create a test application.

RESTful POX

To achieve this the service contract is decorated with REST attributes, That is a WebGetAttribute if you're exposing the operation via GET verb or a WebInvokeAttribute if you're exposing it via POST.

Note : The thing was that exposing IList<T> as a returned result of a service resulted a non functioning service with the following message : "Request Error : The server encountered an error processing the request. See server logs for more details." It turned out exposing the List<T> worked. The reason behind this is probably the same thing as exposing an objectâ€™s interface via normal (Soap) WCF service which also doesn't work due to interfaces not being serializable.

So here's the service contract :

[ServiceContract]
public interface IDataServices
{
    [OperationContract]
    [WebGet(ResponseFormat = WebMessageFormat.Xml, BodyStyle = WebMessageBodyStyle.Bare, UriTemplate = "/Advertisers")]
    List<Advertiser> GetAdvertisers();
}

and the implementation is self explanatory. What you get is a service exposed at a URL like http://localhost/Services/DataServices.svc/Advertisers. In order to get rid of the nasty .svc extension you either need to use IIS URL Rewriting Module which is only available on IIS 7 or use IIS Wildcard Mapping plus a HttpModule to make this happen. Read here for complete information.

Note : The .svc extension does not matter from operational perspective. It is computer applications that connect to these URLs after all, but from purists point of view it does matter.

The final part is the configuration which is standard WCF configuration like identifying service and contract, exposing EndPoints, etc. :

<system.serviceModel>
   <serviceHostingEnvironment aspNetCompatibilityEnabled="true" />
   <behaviors>
     <endpointBehaviors>
       <behavior name="WebBehavior">
         <webHttp/>
       </behavior>
     </endpointBehaviors>
   </behaviors>

   <services>
     <service name="Reklam.UI.Web.Services.DataServices">
       <endpoint behaviorConfiguration="WebBehavior"
                 binding="webHttpBinding"
                 contract="Reklam.UI.Web.Services.IDataServices" />
     </service>
   </services>
</system.serviceModel>

Transferring large DataSets with WCF

HEskandari — Sat, 16 Feb 2008 10:06:00 GMT

I was working on an application which transfered a large amount of data in a DataSet object to a client. Everything worked fine for small amounts of data, but as soon as the DataSet got bigger than 100 rows, client didn't get the message sent by the server anymore!

It took some time to figure out what the problem was. If you're transferring a large amount of data and having the same problem you may need to do two things :

You should set the MaxReceivedMessageSize on your binding to a larger value. If the message sent by the client/server exceeds this value, they will not recieve it. Use this value cautiously because setting it a value larger than the data you can load into your RAM could at least crash the application, and also you might expose your server to Denial of Service attacks.

You might also need to set the MaxArrayLength property of the ReaderQuotas object on your client/server binding, especially if you recieve serialization exceptions when the data is being serialized to be sent to client/server. Remember to add a reference to System.Runtime.Serialization in case you need to do this.

Here's how you can do this :


          NetTcpBinding binding = new NetTcpBinding(SecurityMode.None, true);
          binding.MaxReceivedMessageSize = 10485760;
          binding.ReaderQuotas.MaxArrayLength = 10485760;

Also, if you're transferring data objects like large files, audio or video data, etc. you may consider using streaming message mode of WCF. In this mode, the large message is split into chunks and each chunk is loaded into memory and sent through the service. For more info on this see http://msdn2.microsoft.com/en-us/library/ms731913.aspx.

WCF Shortcomings and Dark Sides

HEskandari — Tue, 05 Feb 2008 11:18:00 GMT

I've been busy for last months, working on not-much-new-anymore, .NET 3.0 foundations, with more focus on WPF and WCF.

Here are some drawbacks and shortcomings I encountered when testing the WCF :

I tried getting a DataSet containing 100 data rows from a service, using TCP binding with reliable session. When the data was bigger than a few KiloBytes, client didn't recieve the message from the service, and because of Reliable Session, service kept sending the results again and again in specific time intervals!

It turned out that there's a setting to specify the maximum message size client can recieve. Client will NOT receive messages larger than that, and what made me wonder is how low the default value is!

There's no way to configure the service client/server from external configuration file or other means, e.g. from database, xml document, etc! You only get two options : configure from code, or application/web config file. Back in remoting days, we could pass a configuration file to the remoting subsystem and let the system configure itself from that file. This is VERY annoying specially for service clients where the application configuration is a bad idea to use if you have curious users running your application! Altough, there's a workaround to use an external configuration file on the client, there's none for the service side. If you're intrested see here

You need a ServiceHost to host a service in self-hosting mode. A service host can not host multiple services. Although, you can use multiple service hosts, but I guess it could be provided out of the box in WCF.

As you see, drawbacks (so far) is very small comparing to all you get using WCF. In case you have something you think is missing from WCF, you can send your feedback to microsoft at their connect site : https://connect.microsoft.com/wcf/ Hopefully, they'll consider it if there's enough votes.