Silverlight Web Services Team : soap

Improving the performance of web services in SL3 Beta

SLWSTeam — Mon, 08 Jun 2009 06:30:04 GMT

Silverlight 3 Beta introduces a new way to improve the performance of web services. You have all probably used the Silverlight-enabled WCF Service item template in Visual Studio to create a WCF web service, and then used the Add Service Reference command in your Silverlight application project in order to access the web service. In SL3, the item template has undergone a small change that turns on the new binary message encoder, which significantly improves the performance of the WCF services you build. Note that this is the same binary encoder which has been available in .Net since the release of WCF, so all WCF developers will find the object model very familiar.

The best part is that this is done entirely in the service configuration file (Web.config) and does not affect the way you use the service. (Check out this post for a brief description of exactly what the change is.)

I wanted to share some data that shows exactly how noticeable this performance improvement is, and perhaps convince some of you to consider migrating your apps from SL2 to SL3.

When Silverlight applications use web services, XML-based messages (in the SOAP format) are being exchanged. In SL2, those messages were always encoded as plain text when being transmitted; you could open a HTTP traffic logger and you would be able to read the messages. However using plain text is far from being a compact encoding when sending across the wire, and far from being fast when decoding on the server side. When we use the binary encoder, the messages are encoded using a WCF binary encoding, which provides two main advantages: increased server throughput and decreased message size.

Increased server throughput

Let’s examine the following graph (hat tip to Greg Leake of StockTrader fame for collecting this data). Here is the scenario we measure: the client sends a payload, the server receives it and sends it back to the client. Many clients are used to load the service up to its peak throughput. We run the test once using the text-based encoding and once using the new binary encoding and compare the peak throughput at the sever. We do this for 2 message sizes: in the smaller size the payload an array with 20 objects, and in the bigger one the payload is an array with 100 objects.

Some more details for the curious: The service is configured to ensure no throttling is happening, and a new instance of the service is created for every client call (known as PerCall instancing). There are ten physical clients driving load, each running many threads hitting service in tight loop (but with small 0.1 second think time between requests) using a shared channel to reduce client load. The graph measures peak throughput on the service at 100% CPU saturation. Note that in this test we did not use Silverlight clients but regular .Net clients. Since we are measuring server throughput it is not significant what the clients are.

When sending the smaller message we see a 24% increase in server throughput, and with the larger message size we see a 71% increase in server throughput. As the message complexity continues to grow, we should see even more significant gains from using the binary encoder.

What does that mean to you? If you run a service that is being used by Silverlight clients and you exchange non-trivial messages, you can support significantly more clients if the clients use SL3’s binary encoding. As usage of your service increases, that could mean being able to save on buying and deploying extra servers.

Decreased message size

Another feature of the binary encoder is that since messages sent on the wire are no longer plain-text, you will see a reduction in their average size. Let’s clarify this point: the main reason you would use the binary encoding is to increase the service throughput, as discussed in the previous section. The decrease in message size is a nice side-effect, but let’s face it: you can accomplish the same effect by turning on compression on the HTTP level.

This test was far less comprehensive than the previous one and we did it ad-hoc on my co-worker’s office machine. We took various objects inside a Silverlight control, and turned them into the same kind of SOAP messages that get sent to the service. We did this using the plain-text encoding and using binary encoding and then we compared the size of the messages in bytes. Here are our results:

The takeaway here is that the reduction of message size depends on the nature of the payload: sending large instances of system types (for example a long String) will result in a modest reduction, but the largest gains occur when complex object graphs are being encoded (for example objects with many members, or arrays).

What does this mean to you? If you run a web service and you pay your ISP for the traffic your service generates, using binary encoding will reduce the size of messages on the wire, and hopefully lower your bandwidth bills as traffic to your service increases.

Conclusion

We are confident that binary encoding is the right choice for most backend WCF service scenarios: you should never see a regression over text encoding when it comes to server throughput or message size; hopefully you will see performance gains in most cases. This is why the binary encoder is the new default in the Silverlight-enabled WCF Service item template in Visual Studio.

An important note: binary encoding is only supported by WCF services and clients, and so it is not the right choice if you aren’t using WCF end-to-end. If your service needs to be accessed by non-WCF clients, using binary encoding may not be possible. The binary AMF encoding used by Adobe Flex is similarly restricted to services that support it.

What's new with web services in Silverlight 3 Beta

SLWSTeam — Fri, 20 Mar 2009 13:18:00 GMT

Silverlight 3 beta comes with a set of exciting web services features that address key customer requests.

Binary message encoding

In Silverlight 2 the only supported binding was BasicHttpBinding, which encodes outgoing messages as text and sends them over an HTTP transport. This binding is great for interoperability with SOAP 1.1 services and is also easily debuggable since messages can be viewed in plain text on the wire using HTTP debugging tools such as Fiddler.

However as Silverlight applications go into production and grow to scale, service developers start getting concerned with the cost of hosting services. Two things in particular that we are about:

Increased server throughput - more clients can be connected to a server, which means fewer servers need to be purchased.
Decreased message size - smaller message sizes exchanged on the wire means lower bandwidth bills

Silverlight 3 introduces a binary message encoder, which produces significant improvements in both of the above indicators. A follow-up post is coming with some specific data on the improvements that can be expected.

Binary encoding is implemented as a custom binding, there is no out-of-the-box binary binding.

The BinaryMessageEncodingBindingElement can be used as part of any custom binding and so it composes easily to create things like a binary duplex binding.

The binary encoder offers performance gains over the text encoder, and there should never be any regressions. This is why binary is the new default in backend service scenarios, such as where the Silverlight-enabled WCF Service item template is used. Therefore the template has been modified to use binary. The interop cases is where binary should not be used (if the client is talking to a non-WCF service), since binary is a WCF-specific encoding: please continue to use BasicHttpBinding with text encoding in those scenarios (for example accessing ASMX services).

Duplex object model simplification

Duplex is an innovative Silverlight 2 feature which allows the service to send data to the client without the client manually polling for the data ("smart" polling still occurs on the network layer, but the user does not need to know). However there were two significant limitations in the Silverlight 2 duplex object model:

Channel programming had to be used and
Serialization was not supported so a Message programming model had to be used.

Silverlight 3 lifts these restrictions and introduces Add Service Reference support for duplex services. Familiar-looking proxies are now generated, greatly reducing the amount of Silverlight code that is needed to access a duplex service. A simple stock ticker client implementation, which previously took 203 lines of code, can now be reduced to a mere 48 lines of code, a 76% reduction in code size. Not to mention that the channel-based code was complex and very error-prone due to its use of async patterns. Here is a snippet showing the crux of the new object model, in the context of the stock ticker example:

private void Button_Click(object sender, System.Windows.RoutedEventArgs e)

{

ServiceClient proxy = new ServiceClient(binding, address);

proxy.ReceiveCallbackCompleted += new EventHandler<ReceiveCallbackCompletedEventArgs>(proxy_ReceiveCallbackCompleted);

proxy.StartAsync(symbol.Text);

}

void proxy_ReceiveCallbackCompleted(object sender, ReceiveCallbackCompletedEventArgs e)

{

if (e.Error == null)

{

price.Text = e.price.ToString();

}

Note that receiving the callback from the server is now just a matter of attaching a callback to an event. Also note the fact that we are working with CLR types and not Message objects, so serialization is now enabled. We have updated our documentation with a walkthrough of how to use the new object model. In addition, Eugene's duplex chat server implementation, which has proven very popular, has also been updated with the new OM.

Faults support

In Silverlight 2 if an unexpected exception occurred in the service, the fault would not be propagated to the Silverlight client. Instead of getting the exception propagated to the user, Silverlight would throw an unhelpful CommunicationException which carries no useful information. There were two reasons for this: (1) faults are returned with a 500 status code, and the browser networking stack prevents Silverlight from reading the body of such a response, and (2) Silverlight did not support he necessary client-side logic to convert the fault message into an exception that can be surfaced to the user. These limitation made it very difficult to debug services from Silverlight.

In Silverlight 3 Beta limitation (1) is unfortunately still present. To work around this issue our documentation provides a WCF endpoint behavior, which can be applied to your WCF service to switch the response code from 500 to 200. With this response code the message will be accessible to Silverlight and we can address limitation (2). In Silverlight 3, we have added the necessary client-side OM to surface faults to the user. Look out for helpful FaultException and FaultException<ExceptionDetail> exceptions which will help you debug your service. Also please see the documentation page linked earlier for a full description of the faults object model in Silverlight.

New security mode

A common scheme used to secure services for use by Silverlight clients is browser-based authentication. However browser-based authetnication is not safe to use if your service is accessible from any domain via a cross-domain policy file. This would expose your service to CSRF type attacks, where cached browser credentials can be used by malicious apps to access your sercure service without the user's knowledge.

Silverlight 3 introduces a new security mode called TransportSecurityWithMessageCredential to address this configuration. In this mode, the credentials are included in every outgoing message to the service, and the service verifies those credentials on the SOAP layer. However since the credentials are in plain text inside the message the transport needs to be secure so we use HTTPS.

A more detailed walktrhough of valid Silverlight security configurations will follow.

Command-line proxy generation

In Silverlight 2 Add Service Reference as part of Visual Studio is the only way to generate proxies for Silverlight clients. In Silverlight 3 we are introducing a command-line tool called slsvcutil.exe, which allows customized command-line proxy generation. Using the tool, proxies can now be generated as part of your build process for greater robustness. The slsvcutil.exe tool is fully described in this documentation topic.

Thanks for reading through this, and please stay tuned for some in-depth posts about these new features.

Yavor Georgiev
Program Manager, Silverlight Web Services Team

New Web Services Features in Silverlight 2 RTW

SLWSTeam — Mon, 20 Oct 2008 16:39:00 GMT

Here is an overview of the new features added since Beta 2.

SOAP Headers

SOAP headers were a big customer request, so we have added headers support in this release. There are two methods to use headers, depending on the customer scenario.

The easier method is useful when you need to get/set a header while invoking a single operation on the service. You can use the OperationContext class, and specifically the IncomingMessageHeaders or OutgoingMessageHeaders property to receive or send a header. Below is a code example where the client sends the header <MyClientHeader xmlns="http://silverlight.net">...</MyClientHeader> to the service.


public Page()
{

     InitializeComponent();
     // Instantiate generated proxy
     Service1Client proxy = new Service1Client();

     // Hook up an event handler when operation completes
     proxy.DoWorkCompleted += new EventHandler<DoWorkCompletedEventArgs>(proxy_DoWorkCompleted);
     using (OperationContextScope ocs = new OperationContextScope(proxy.InnerChannel))
     {

     // We can add "MyClientHeader" SOAP header to the outgoing message. It is important that this comes before calling the operation.
     OperationContext.Current.OutgoingMessageHeaders.Add(MessageHeader.CreateHeader("MyClientHeader", "http://silverlight.net", "..."));

     // Call an operation on the service
     proxy.DoWorkAsync("foo");

     }
}

Now assume we want to get at a header that the service sent back. In this example, the service sent the <MyServiceHeader xmlns="http://silverlight.net">...</MyServiceHeader> header to the client. Note: The old Begin*/End* async pattern needs to be used with OperationContext if you are retrieving the headers sent in a service reply. The event-based async pattern (using *Completed event and *Async method) is currently not supported. Also, please be sure to use exact order of calls demonstrated below.


public Page()
{

     InitializeComponent();
     // Instantiate generated proxy
     Service1Client proxy = new Service1Client();

     // Call an operation on the service using Begin/End async pattern
     ((Service1)proxy).BeginDoWork("foo", doWorkCallback, proxy);

}
// Receive callback when the service responds
void doWorkCallback(IAsyncResult result)
{
     Service1 proxy = (Service1)result.AsyncState;

     using (OperationContextScope ocs = new OperationContextScope(((Service1Client)proxy).InnerChannel)) 
     {

          // Get the service response. This needs to happen before we access the headers.
          string response = proxy.EndDoWork(result);

          // Now we can access the headers of the incoming message. In this case we assume the header "MyServiceHeader" was sent by the service.
          string headerContents = OperationContext.Current.IncomingMessageHeaders.GetHeader<string>("MyServiceHeader", "http://silverlight.net");

          // Do something with response and header

} }

The harder method can be used when you want to get/set headers upon invoking any operation on the service. In that case you would have to use OperationContext every time you call a service operation, which is very clunky. Instead, what would be useful is functionality similar to that provided by WCF message inspectors and the IClientMessageInspector class. Using a client message inspector you can get access to the Message instance just received from or about to be sent to the service, and manipulate the headers directly on the instance. IClientMessageInspector is not part of SL 2, but this code sample demonstrates how to accomplish the same functionality. In the sample, we add a header to every message sent to the service, and the header contains the IP address of the client which is calling the service.

SOAP Faults

Eugene posted about faults just a couple of weeks back. Faults are another major request but unfortunately they are not supported out of the box in SL 2. However, using the same client message inspectors approach and some extra configuration on the WCF service side, rudimentary faults can be enabled. The same code sample linked above demonstrates how to do this. I will put together a more detailed post about the sample in the coming weeks.

Reusing existing types in "Add Service Reference"

If you use "Add Service Reference" to add a reference to the service in your client, it will by default generate a duplicate of any type used by your service operation. Frequently when developing a WCF service and a Silverlight client, you want to declare your types in only one place. Alternatively, maybe your data contract types contain internal logic that you would like to preserve and that logic is lost when "Add Service Reference" generates the duplicate types in the client.

To prevent duplicate types from being generated in the client, you would normally declare the data contract types in a new project, which is referenced by both your WCF service and the Silverlight client. Then when adding a reference to the service, you would select the correct option in the "Add Service Reference" dialog. This way "Add Service Reference" would find the types already referenced in the shared project, and not generate duplicates.

Note: In Silverlight the shared project that contains the data contract types has to be a "Silverlight Library", which can be referenced by both Silverlight projects and regular desktop framework projects. If the shared project is of any other type, you will not be able to reference it from within a "Silverlight Application" project.

This option was already there in the Silverlight version of "Add Service Reference", but it did not work up until this release.

Duplex Services

We have made improvements to the duplex channel shipped in Beta 2:

Client and server side duplex components are now ready for production use, with improved stability, security, etc. In Beta 2 the server-side duplex component was under an "evaluation" license.
Server-side duplex component may now be hosted in Partial Trust
Default timeouts and timeout behavior is “smarter” – no changes should be required for common scenarios

In addition, Eugene has developed a great sample on top of the raw duplex channel model, to simplify duplex usage. On the client side you can use the DuplexReceiver class:


public class DuplexReceiver
{
     // Opens a channel to the service to receive messages using the default PollingDuplexBinding
     public DuplexReceiver(Uri address, IEnumerable<Type> possibleTypes);

     // Opens a channel to the service to receive messages using the default PollingDuplexBinding
     public DuplexReceiver(EndpointAddress address, IEnumerable<Type> possibleTypes);

     // Sends a message to a Duplex service. (The first time a message is sent, connection will be established to the service).
     public void SendMessageAsync(object message);

     // Event that will be called after a message has been sent
     public event EventHandler<AsyncCompletedEventArgs> SendMessageCompleted;

     // Event that will be called for each received message
     public event EventHandler<ReceivedMessageEventArgs> MessageReceived;

     // Disconnects from a Duplex service (can later reconnect again). To permanently close, first call DisconnectAsync and then call Close
     public void DisconnectAsync();

     // Closes the Duplex connection
     public void Close();

     // Other methods and properties omitted for brevity...

}

Instead of using the channel model directly, you can use the SendMessageAsync method to send messages to the service. The MessageReceived event is fired when the service sends the client a message. Note that the DuplexReceiver contructor takes the list of types that can possibly be sent. The sample also provides a server-side DuplexService object, which keeps track of connected clients and can relay messages to the correct recipient, or broadcast messages to all clients.

Support for ChannelFactory<T>

This is an advanced use case: say you want to use a service without generating a proxy to it. Perhaps you are connecting to a complex service and you manually copied over/shared all the contracts and types that the service uses (for example in order to preserve the internal logic of these types). But you never used the "Add Service Reference" wizard so you don't have a proxy class to the service. In this case ChannelFactory<T> can be used to communicate with a service which implements the service contract <T>, as shown below.


public Page()
{
     InitializeComponent();

     ChannelFactory<Service1Channel> factory = new ChannelFactory<Service1Channel>(
          new BasicHttpBinding(),
          new EndpointAddress("http://localhost:49507/Service1.svc"));

     Service1Channel channel = factory.CreateChannel();

     channel.BeginDoWork(new AsyncCallback(doWorkCallback), channel);
}

void doWorkCallback(IAsyncResult result)
{
     Service1Channel channel = (Service1Channel)result.AsyncState;
     string response = channel.EndDoWork(result);

     // Do something with response
}

Note that using this approach, the event-based async pattern is not supported.

Other

Types generated from ADO.NET Entity Data Models (.edmx files) in WCF services intended for Silverlight consumption are now supported. Just use the type generated from a .edmx model as an argument in a service operation.
Internal types and internal members may now be serialized by the DataContractSerializer and the DataContractJsonSerializer (on a per-assembly opt-in basis)
JSON/XML Mapping is now supported (through System.Runtime.Serialization.Json.dll in the SDK), by using the JsonReaderWriterFactory class.
JAXB-style object references in XML are now supported by DataContractSerializer

Have fun using our new feature set!

Yavor Georgiev
Program Manager, Connected Framework Team

Detailed Overview of Silverlight 2 Beta 2 Web Service Features

SLWSTeam — Tue, 10 Jun 2008 11:21:00 GMT

As you have probably read already (in Scott or Tim's posts), Silverlight 2 Beta 2 provides a set of new and improved web service features. This post will go over our Beta 2 scenarions in more detail, and we intend to follow up over the next couple of weeks and drill down into particualr features.

Duplex Communication (Server Push)

This has been the most requested feature from our customers since the release of Beta 1, and it enables some useful scenarios like building chat and monitoring apps. Duplex allows the client to expose a set of operations that the server can call to send (push) information to the client. Previously addressing the browser-based client was not possible using the web service stack, so we are very excited to ship this feature in Beta 2.

Duplex support is delivered in two assemblies: one that plugs into your WCF service, and the other one which plugs in to the Silverlight client. Once you install the Beta 2 SDK, you will get the following assemblies:

C:\Program Files\Microsoft SDKs\Silverlight\v2.0\Libraries\Server\Evaluation\System.ServiceModel.PollingDuplex.dll

This is the server-side assembly. For details on it usage and how to build a duplex WCF service, see this topic in the documentation. The assembly provides you with the server-side PollingDuplexBindingElement, which allows you to build a custom binding, You can then build a custom ServiceHost, which uses the custom binding to host your service contract. A service contract hosted this way will support ServiceContractAttribute.CallbackContract, which is how you specify the client operations that the service can call. The topic referenced above goes through all these details and shows you a finished duplex WCF service.

You may have noticed the "Evaluation" folder name in the path. This assembly is provided on a different license than the rest of the Beta 2 product, and is not meant for production apps. We intend to put some more work into the API and tune the performance before this component is ready for production environments.
C:\Program Files\Microsoft SDKs\Silverlight\v2.0\Libraries\Client\System.ServiceModel.PollingDuplex.dll

This is the client-side duplex assembly. For details on its usage and how to build a Silverilght client for a WCF duplex service, see this topic in the documentation. The assembly provides you with the client-side PollingDuplexHttpBinding, which can be used to create a channel to talk to the WCF duplex service. This is covered by the above topic.

You might remember Eugene's blog post, which talks about a typed "receiver" experience, which also takes care of deserialization. We are working on this and will likely release it as a code sample on silverlight.net in the coming weeks.

LINQ over JSON

Many web services provide APIs which return JSON data instead of POX or SOAP, and we want to make sure Silverlight provides great support for these types of services. So far the only way to interact with JSON in Silverlight has been to deserialize it into a type, which we have defined already to match the structure of the JSON. However this becomes impractical for APIs that return a lot of JSON data. Take Facebook for example: just asking for a user's information returns almost a page of JSON, and it would be impractical for a Silverilght developer to have to construct a type to match this JSON, especially if the Silverlight app is a mashup and interacts with multiple complex JSON APIs. In situations like this, we would prefer to "dot into" the JSON object and treat it as more of a dictionary, as opposed through the deserialization mechanism.

Beta 2 introduces a brand new feature called JsonObject, which is also new to the .Net platform. JsonObject allows you to "parse" a JSON string and then use it as a dictionary in Silverlight, as shown in this documentation topic. Using the following JSON string as an example,

[{"IsMember" : true, "Name" : "John", "Age" : 24}, 
{"IsMember" : false, "Name" : "Paul", "Age" : 44},
{"IsMember" : true, "Name" : "George", "Age" : 12}]

we can parse it into the JsonObject users, and then access its members this way: users[0]["Name"], users[1]["Age"], etc. We can then construct LINQ expressions such as


var members = from member in users
              where member["IsMember"]
              select member;

The FoodFinder sample on silverlight.net provides a real usage example of the Yahoo! Local JSON API (download the source code). The following LINQ query is used by the sample to dynamically filter the results returned by the service based on two sliders that the user controls.


var members = from restaurant in (JsonArray)results["ResultSet"]["Result"]
              where float.Parse(restaurant["Rating"]["AverageRating"]) >= rating.Value
              where float.Parse(restaurant["Distance"]) < distance.Value
              select restaurant;

Configuration Support

In Beta 1, the binding and endpoint address had to be specified in code and passed as parameters to the proxy constructor.


BasicHttpBinding binding = new BasicHttpBinding();
EndpointAddress address = new EndpointAddress(http://localhost/service.svc);
ServiceClient proxy = new ServiceClient(binding, address);

In Beta 2 the "Add Service Reference" feature in Visual Studio will generate a ServiceReference.clientConfig file, which will contain the binding and address configuration informaton, and the proxy can be constructed with its default constructor.


ServiceClient proxy = new ServiceClient();

This allows us to change the binding/address without needing to recompile the Silverlight control. In addition configuration exposes some knobs on the binding, which can be tweaked for security or performance reasons:


<binding name="BasicHttpBinding_IService" closeTimeout="00:59:00" openTimeout="00:53:00"
         receiveTimeout="00:15:00" sendTimeout="00:21:00" maxBufferSize="65530"
         maxReceivedMessageSize="65531" textEncoding="utf-8" />

This documentation topic explains the different settings available.

Tooling Improvements

We have added the "Silverlight-enalbled WCF Service" Item template. When a WCF service is added using this template, the binding in the service configuration is automatically switched to basicHttpBinding.

IntelliSense over .clientConfig files is now supported. As you start editing the file you will get useful popups with the supported schema.

SOAP Improvements

We have made some general SOAP improvements in Beta 2:

Custom SOAP headers and faults in service - ignored and don't generate uncompilable code
“Wildcard” schema in service (like xsd:any or xsd:anyattribute) - now works and doesn't generate uncompilable code

And specifically if your service is a WCF (or in some cases .ASMX) service:

XML types like XmlElement/XElement/XmlNode[]/XmlAttribute/etc in service - now work and don't generate uncompilable code
Types that implement ISerializable in your service (except for collections) - now work and don't generate uncompilable code
Stream type in service - now works and doesn't generate uncompilable code
MessageHeaderAttribute in Message Contracts - ignored and doesn't generate uncompilable code

Please keep an eye on this blog for more specifics in the next couple of weeks.

Cheers,
-Yavor Georgiev
Program Manager, Connected Framework Team

Debugging Web Service Usage in Silverlight 2

SLWSTeam — Wed, 16 Apr 2008 21:29:00 GMT

(Cross-posted from http://eugeneos.blogspot.com/2008/04/debugging-web-service-usage-in.html)

Silverlight 2 Beta1 makes it easy to use Web Services based on either the WCF technology (Windows Communication Foundation), the “.asmx” technology (ASP.NET Web Services), or practically any other SOAP platform.

Unfortunately, when something goes wrong with service consumption, you often run into cryptic and incomprehensible error messages that don’t help you much. We are looking into various ways to make this better by the time we fully ship Silverlight 2, but for now I hope that this post will be useful in helping you debug common problems. Here are the things you can try:

Does your proxy compile?

After you use the “Add Service Reference” dialog to add a reference to a service, try building your project. If you get compilation issues in the generated proxy code, you are probably using a service that uses some feature that is not supported in Beta1. We are trying to fix all or most of these by the time we ship, but for now the easiest thing to do is to find the offending code in the generated proxy and just remove it – naturally this workaround does not work in all cases :) Some common things that will cause non-compilable proxies in Beta1:

- Using custom SOAP headers in your service
- Using custom SOAP faults
- Using “wildcard” schema in your service like xsd:any or xsd:anyattribute

And specifically if your service is a WCF (or in some cases .ASMX) service:

- Using XML types like XmlElement/XElement/XmlNode[]/XmlAttribute/etc. in your service
- Using Datasets in your service
- Using types that implement ISerializable in your service (except for collections)
- Using WCF Transactions features
- Using the Stream type in your service
- Using MessageHeaderAttribute in Message Contracts

Check the Configuration

The next step is to check whether the service is configured correctly. You should have a file called ServiceReferences.ClientConfig generated by Add Service Reference. It actually doesn’t do anything at all in Beta1! This (understandably) confuses a lot of people. Starting with Beta2, we will actually start using this file, but for now any changes that you’ll make in it won’t actually affect anything.

However, the file is still useful for debugging. Look in the file – it should look something like this:

Notice that it has exactly one endpoint element for the service you just added a reference to, and the binding is basicHttpBinding.

If you don’t see an endpoint element for your service, chances are your service wasn’t actually configured correctly for Silverlight consumption. Silverlight can only talk to simple SOAP services at this point – only SOAP 1.1, without any advanced WS-* protocols like WS-Addressing or WS-Security. If you are using “.ASMX” web services, they should just default to this simple configuration. If you are using WCF services, you need to check the configuration on the service side. Open web.config in your service-side project and find a place that looks like the following (usually towards the end):

<system.serviceModel>
...
<services>
<service name="MyProject.TestService">
<endpoint address="" binding="basicHttpBinding" contract="MyProject.ITestService" />
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
...
</service>
</services>
</system.serviceModel>

Find the endpoint whose “contract” attribute refers to your service. Make sure that the “binding” attribute is set to “basicHttpBinding”. Unfortunately the default for WCF is “wsHttpBinding”, but it doesn’t work with Silverlight. We are hoping to ship a Visual Studio item template in the future (“Add New Item… Silverlight-enabled WCF Service”) that will have a number of Silverlight-friendly defaults, including the correct binding.

It is ok to have other endpoint elements for other contracts with other bindings - for example, do not change the "mexHttpBinding" in the second endpoint element above.

You should check your service-side configuration even if the client-side ServiceReferences.ClientConfig appears to be correct.

If ServiceReferences.ClientConfig contains more than one endpoint for your service, you may need to use a more complicated constructor to new up your service proxy – the one that takes a Binding and an EndpointAddress. Not to worry – just pass a new BasicHttpBinding() and a new EndpointAddress built from the URL of your service.

By the way, our long-term (post-Beta1) plans for the config file are described here: http://blogs.msdn.com/suwatch/archive/2008/04/07/tutorial-using-silverlight-web-service-client-configuration.aspx

Check if the Service is Running

Before looking for problems on the Silverlight side, it is useful to first check whether the service itself is working. A quick-and-dirty way to check is to just type the service address into a web browser (not the address you typed into the “Add Service Reference” dialog, but the address you can find in ServiceReferences.ClientConfig). In many cases, the “service help page” feature will be turned on and you will see either a page indicating that the service is running, or an error page which you can use as a starting point for debugging.

A more reliable way to test whether the service is working is to use a test tool such as the WCF Test Client (http://msdn2.microsoft.com/en-us/library/bb552364.aspx) to try and talk to the service.

Finally, an almost sure-fire but sometimes lengthy way of finding out whether the problem is with the Silverlight code or with the service code is to try using the service without Silverlight :) Just create a new project of type “Console Application”, do an Add Service Reference to that project just like in Silverlight, and write service consumption code inside Main() – again, just like in Silverlight. Use Console.WriteLine to show the results.

Check for Cross-Domain Issues

Start your Silverlight application. Note the URL that appears in the browser (e.g. http://localhost:1111/something/MyGraphicalApp.aspx) – this is your “Application URL”. (Actually, what matters here is the URL of the XAP file, e.g. http://localhost:1111/somethingelse/MyGraphicalApp.xap, but in most simple cases this URL would be in the same domain as the hosting web page, so I’m ignoring the difference for now). Then, look at the URL in the ServiceReferences.ClientConfig file – e.g. http://localhost:5678/foo/TestService.svc or local.live.com/SearchService/LocalSearch.asmx - this is your “Service URL”.

In Beta1, both the “Application URL” and the “Service URL” must be HTTP URLs (not HTTPS) for service consumption to work. This is the first thing to check.

Also, a common mistake is to run your Silverlight application from a file:// Application URL, resulting in cross-domain issues. Sometimes, you run into this if you just hit F5 to run your Silverlight app – instead, right-click on the .aspx page in your project and choose “View in Browser”.

Now you need to figure out the domains for these URLs. The domain is just the basically everything between http:// and the first slash / after that, including the port number (assumed to be 80 if not present). If the domain of the Application URL is different in any way from the domain of the Service URL in any way (even if it’s just a port number difference, or just one part of the domain name is different), you have a cross-domain situation. For example, if your app is at http://localhost:1111/something/MyGraphicalApp.aspx and it is trying to call into http://localhost:5678/foo/TestService.svc, you have a cross-domain situation because localhost:1111 is different from localhost:5678.

Silverlight documentation tells you that if you are in a cross-domain situation, you need to have a “cross-domain policy file” (clientaccesspolicy.xml or crossdomain.xml) present if you want services to work. There is an easy way to check if you have everything set up correctly: Just open a browser and browse to http://service_domain/clientaccesspolicy.xml and http://service_domain/crossdomain.xml. If at least one of these is present, valid and allows cross-domain access – you’re fine. If not, you need to make sure at least one of these files is present.

A common mistake is to put the cross-domain policy file not directly at the root of the domain – for example, at http://localhost:5678/foo/clientaccesspolicy.xml instead of at http://localhost:5678/clientaccesspolicy.xml. It is easy to run into this situation when working with older (.NET 2.0) projects – see http://timheuer.com/blog/archive/2008/04/09/silverlight-cannot-access-web-service.aspx.

Also, make sure to check the syntax of these files – an error in parsing will be treated essentially the same way as if the file was not there. Also note that clientaccesspolicy.xml and crossdomain.xml have different syntax – make sure you use the appropriate content for the file you choose.

A neat trick for adding cross-domain policy files to WCF services that are not hosted in IIS is described here: http://blogs.msdn.com/carlosfigueira/archive/2008/03/07/enabling-cross-domain-calls-for-silverlight-apps-on-self-hosted-web-services.aspx

Enable Exceptions

Normally, Silverlight does not give you much information in exception messages. This decision was made to make the Silverlight download size smaller (exceptions take up a lot of space, especially once they’re translated into all of the languages Silverlight supports). You can read more about this, and find out how to turn on full exceptions for debugging, here: http://blogs.msdn.com/silverlightws/archive/2008/04/06/getting-full-exceptions-in-silverlight-2-beta-1.aspx

Also, if you are using a WCF service, WCF does not normally return much information about server-side exceptions. This is a security measure: you normally don’t want to expose internal information about your service to the outside world. However, during debugging, you can change this by following the steps here: http://blogs.devdeo.com/carlos.medina/PermaLink,guid,b3bff742-0ec9-4f5c-a178-625220a46652.aspx. Make sure to turn it off once you’re done debugging!

Finally, this seems obvious but a lot of people forget about it for some reason - when you get an exception, don’t just look at the exception itself - look at its innerException, and the innerException inside it, etc. Especially in web service scenarios, the truly useful exceptions are often “wrapped” in several layers.

Unfortunately, even with all of the steps above, you often still won’t see much useful information when a web service call fails. This is due to a pretty fundamental limitation of Silverlight Beta1 (that unfortunately may stay around even after the Beta) – the lack of support for SOAP Faults. So, to truly debug, you need to see what is actually going on – this is what the next section is about.

Getting Down to the Wire

The ultimate way to debug Silverlight service consumption issues is by using an “HTTP spying” tool such as http://www.fiddlertool.com/fiddler/ or http://projects.nikhilk.net/webdevhelper/ that shows you the actual HTTP traffic as it happens. Before using it, make sure to enable server-side exceptions (see above). Start your Silverlight app and your tool side-by-side, and make your app do a web service call. Here are some common patterns you will see:

1.Nothing
- Your HTTP spying tool may be misconfigured (try running another, non-Silverlight app, like a regular web browser, to make sure it works)
- Your app may be broken – put a breakpoint where you invoke the service, make sure it’s hit
- You may have a configuration issue – see Configuration section above
- You may be trying to host your application from a file:// or https:// URL, or trying to call an https:// service

2. Just a service request
- Congratulations – you’ve avoided a cross-domain situation if you see the actual request to the service on the wire.
- Is the address what you expected it to be?
- Look at what’s coming back. Is it timing out or are you getting a 404? Your service or even WCF itself may not be set up correctly.
- Are you getting a SOAP fault back? If so, read carefully what’s in the fault – it will usually have enough information to debug the issue.
- In general, look very carefully at both the request and the reply (including the body and HTTP headers)
- Did you remove anything to get the proxy to compile? The service may actually require some items that you removed (e.g. may require certain SOAP headers)

3. A request to clientaccesspolicy.xml (and possibly crossdomain.xml afterwards), followed by a request to the service
- Congratulations – you have a cross-domain situation but you have successfully set up your cross-domain policy files
- This is now equivalent to situation #2 above

4. Just a request to clientaccesspolicy.xml and nothing else
- Most likely a malformed clientaccesspolicy.xml, or one that contains a policy that forbids cross-domain access

5. A request to clientaccesspolicy.xml, then crossdomain.xml, then nothing else
- Basically, something went wrong with cross-domain policy files.
- Are you getting 404s back? Check if you’re hosting the files correctly and at the correct locations
- Are you getting the actual files back? They may be malformed or may forbid cross-domain access

-- Eugene Osovetsky, Program Manager, Silverlight Web Services team