Silverlight Web Services Team

Adoption of Silverlight serialization and communication technologies in web applications – October 2009

2009-10-16T20:47:55Z

We have repeated the research of the adoption of communication and serialization technologies in Silverlight applications that was originally done in February 2009. The new report is based on a research done in October 2009 and will give you an idea of the changing preferences of Silverlight developers. Enjoy and let us know what you think.

Tomasz Janczuk
Development Manager
WCF Team

Having a PollingDuplex service and any other WCF service in the same website causes Silverlight calls to be slow

2009-09-30T23:50:00Z

After polling duplex support for WCF was released in Silverlight 2 (http://msdn.microsoft.com/en-us/library/dd470105(VS.95).aspx), some customers reported the issue that when a polling duplex service co-exists with normal WCF service on the same IIS web application, the WCF service might be significantly slowed sometimes.

In this post we will show you the process the team followed to resolve the issue. Hopefully you will find this useful in debugging your own SL apps when you encounter a problem. Please see the end of the post for the solution.

The first thing we have to do is to create some code that reproduces the issue. After contacting customers to get there scenarios and settings, we are able to create a test Silverlight application and ASP.Net web application that consistently reproduce this issue (see attached probject). Our test application has two client proxies, one polling duplex based stock ticker and one normal BasicHttpBinding-based calculator. Once the xap is loaded, calculator proxy will start continuously calling the “Add” method of the calculator. The app also has a checkbox which will cause the stock ticker service to start sending periodic stock price updates to the SL client, so at this point the SL all will be using both the regular WCF service and the polling duplex service.

By doing some research we identified that the following features could be influencing the observed slow behavior:

· Using WCF’s ASP.Net Compatibility Mode

· Using ASP.Net sessions

· Selecting between the Silverlight BrowserHttp or ClientHttp stack

We then ran a series of tests to determine when we could observe the slowness reported by our customers.

	Browser Http	Client Http
ASP.Net compat mode enabled Session enabled.	Slow	Normal
ASP.Net compat mode enabled Session disabled	Normal	Normal
No ASP.Net compat	Normal	Normal

As it shows above, the slowdown of the WCF call happens when the services are hosted in ASP.Net compat mode AND when user enabled ASP.Net sessions. The ASP.Net session is enabled when your web application has a global.asax file and it contains a session_start method. It turns out when the ASP.Net session state is enabled, requests for the same session will be processed sequentially. So the calls to the responses for the regular WCF service will get queued up behind the long polls made to the polling duplex service.

Using Fiddler, we can capture the HTTP packages and see the mechanism that ASP.Net uses to enable the session. It is enabled by setting the ASP.NET_SessionId cookie from service side.

POST /PollingWcfServices/ServiceWcf.svc HTTP/1.1

Accept: */*

Content-Length: 564

Content-Type: application/soap+xml; charset=utf-8

Accept-Encoding: gzip, deflate

User-Agent: Mozilla/4.0

Host: foo

Connection: Keep-Alive

Pragma: no-cache

Cookie: ASP.NET_SessionId=iyr4sf55rm1kypafjdvlhm55

This is why the client stack can work around the concurrent requests issue. By default when you use client stack, cookies are not automatically maintained between requests so the cookie set on the server is not returned in the subsequent request. Without the cookie ASP.Net doesn’t know which session to lock and it doesn’t lock it.

To work around the slowness, the user can switch to using the client stack to access both services. If the user wants to take advantage of ASP.Net sessions for the regular WCF service, they can use the browser stack for the regular service and the client stack for the polling duplex service. Currently the polling duplex service cannot be used with the browser stack if ASP.Net sessions are enabled. Here is the documentation page on how to register the browser or client stack for a given service.

All WCF services require read/write session state access if you enable ASP.Net sessions, which causes the replies to be queued sequentially. Ideally user should be able configure the WCF handler to be read only, which would allow polling duplex services to work with sessions. Unfortunately this is unsupported at this point.

Instruction for running the sample

1. Run Visual Studio as administrator

2. Enable anonymous authentication on the web application created by the project

Scale-out of Silverlight HTTP polling duplex WCF service in a web farm scenario

2009-09-17T04:08:20Z

The recent post about performance of Silverlight HTTP polling duplex protocol pointed out scalability challenges associated with deploying a WCF service using the protocol in a web farm scenario. This follow up article introduces one possible solution to the scale-out problem, enabling applications utilizing the protocol to accommodate an arbitrary number of concurrent clients through scale-out of the backend infrastructure.

Let us know what you think!

Tomasz Janczuk
Development Manager
WCF Team

Channel9 WCF duplex demo

2009-08-27T10:30:56Z

Recently I spent some time with Robert Hess over at Channel9 discussing Silverlight 3 and giving a short demo of our duplex binding. If you haven’t seen PollingDuplex in action, this might be of interest.

Cheers,
-Yavor Georgiev
Program Manager, Connected Framework

Using web service faults with the new SL3 client HTTP stack

2009-08-17T20:31:42Z

Carlos, one of our team members, has posted an quick blog post on how to use SOAP faults with the new client HTTP stack, introduced in SL3. This makes configuring faults significantly easier: there is no need to write custom code in your WCF service, and all you need to do is add one line of code to the Silverlight client.

Enjoy!

-Yavor Georgiev
Program Manager

AJAX client for HTTP polling duplex WCF channel in Microsoft Silverlight 3

2009-08-06T03:33:10Z

If you are interested in coding an AJAX client application that consumes asynchronous data notifications from a WCF backend service using the Microsoft Silverlight 3 HTTP polling duplex channel, check out the AJAX client for HTTP polling duplex sample. It contains a JavaScript library with client side implementation of the polling duplex protocol implemented in the PollingDuplexHttpBinding from Microsoft Silverlight 3. It has been tested with Internet Explorer 8, Firefox 3.5, and Chrome 2.0. Let us know what you think.

Tomasz Janczuk
Development Manager
WCF Team

Pub/sub sample using HTTP polling duplex WCF channel in Microsoft Silverlight 3

2009-07-25T03:26:31Z

We now have a sample implementation of a pub/sub scenario that uses the HTTP polling duplex WCF channel shipped in Silverlight 3. The sample demonstrates some of the best practices for implementing performance-conscious duplex scenarios using the PollingDuplexHttpBinding, as well as the usability benefits of duplex WCF proxies generated using the Add Service Reference feature of Visual Studio in Silverlight 3. Check out the full description of the polling duplex sample and access the source code, then let us know what you think.

Tomasz Janczuk
Development Manager
WCF Team

Adoption of WCF technologies in Silverlight 2 applications on the web

2009-07-10T02:32:46Z

If you are interested in what communication and serialization technologies are being used by others in Silverlight 2 applications, check out the post at http://tomasz.janczuk.org/2009/07/adoption-of-wcf-technologies-in.html. It is a summary of a research of over 700 actual Silverlight 2 applications conducted in February 2009. It compares the adoption numbers of several communication and serialization technologies, including WCF, in Silverlight 2 applications as well as provides basic analysis of backend service technology.

Tomasz Janczuk
Development Manager
WCF Team

Improving the performance of web services in SL3 Beta

2009-06-08T06:30:04Z

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.

Check us out at TechEd North America 2009

2009-04-20T10:32:01Z

I hope you enjoy the content we post on this blog. I’ll be giving a talk at the upcoming TechEd conference in LA, going through some Silverlight 3 content similar to what we have been posting here. If you’re attending TechEd, check out:

SOA03-INT Interacting with Web Services Using Microsoft Silverlight

Yavor Georgiev
Tue 5/12 | 4:30 PM-5:45 PM | Blue Theater 2
300 - Advanced, Middle Tier Platform and Tools, SOA and Business Processes, TLC Interactive Theater

Learn how easy it is to utilize POX, REST, RSS, ATOM, JSON, and SOAP services in your Silverlight 2 mash-up application. Hear best practices for developing and consuming secure services within and across domain boundaries. Experience new features in the upcoming Silverlight 3 release including optimized binary communication format, improved support for server- to-client "push" scenarios and new security features.

If you have not registered, you still have the opportunity to do so:

If you do attend, make sure you let me know you’re a reader of our blog… I’d love to hear any feedback you have.

Cheers,
-Yavor

Using WCF services from Silverlight in Azure

2009-04-09T02:15:00Z

With all the buzz around Windows Azure, you may have wondered how to host your Silverlight application in the cloud. Since Silverlight controls are essentially static content, hosting them is as easy as uploading some files to the cloud.

When it comes to building WCF services to provide data to your Silverlight control, the story gets a little more complicated. The fact that the Azure cloud is a load-balanced environment as well as the deployment mechanism for setting up a service in Azure pose some unique challenges to hosting WCF services.

To help with this, our team has posted a Code Gallery site with 3 Silverlight-specific samples that you can run in the cloud and also on your local machine. The samples exercise the following features:

Sample #2: binary encoding
Sample #4: message credentials authentication over HTTPS
Sample #5: duplex (server “push”)

The third example hosts our chat sample in Azure for a massively-distributed free-for-all chat experience, and you can try it here. Try opening up this link across multiple machines and browsers and watch them all chat together.

Which brings me to probably the most useful thing we published: a list of known issues with hosting WCF services and Silverlight clients in Azure. Check out this page, and especially the sections “Hosting WCF Services” and “Hosting Silverlight Clients”. The page contains some workarounds we gathered from across the web, and is guaranteed to save you a bunch of head-scratching if you try WCF on Azure for yourself.

Cheers,
-Yavor

Some known issues in SL3 Beta

2009-04-06T08:21:00Z

We've run across some issues with our web services features in the Silverlight 3 Beta and I want to share these here to hopefully save folks some time and frustration.

Issue: On Windows 7 Beta, you might encounter the following error when generating a proxy: "The element 'httpTransport' cannot contain child element 'extendedProtectionPolicy' because the parent element's content model is empty".

Workaround: On Windows 7, when you use the Silverlight-enabled WCF Service item template, an <extendedProtectionPolicy /> element may be generated in Web.config. This element is not supported by Silverlight. Simply remove the element from Web.config and try regenerating the Silverlight proxy.

Issue: If you use the Silverlight-enabled WCF Service template and you try generating a Silverlight proxy using Add Service Reference on a machine with both Silverlight 2 and Silverlight 3 Beta SDKs, you may get warnings at proxy generation time and errors at runtime. The warnings can include a variety of "Cusom tool" warnings which state that the endpoints found are "not compatible with Silverlight 2" or "No endpoints compatible with Silverlight 2 were found."

Workaround: If you are using Add Service Reference to generate proxies, side-by-side installation of the Silverlight 2 and Silverlight 3 Beta SDKs is not supported. Please uninstall the Silverlight 2 SDK to use Silverlight 3 features. After uninstalling, ensure that the assembly Microsoft.Silverlight.ServiceReference is not present in the machine GAC.

Issue: When using Add Service Reference to generate a proxy to a WCF duplex service (a service built with the System.ServiceModel.PollingDuplex.dll assembly provided in the Silverlight SDK), the generated proxy may not compile and may complain about a missing assembly reference.

Workaround: The proxy for the duplex service is generated correctly, however Add Service Reference will sometimes forget to reference th System.ServiceModel.PollingDuplex.dll assembly in the Silverlight client. Simply add a reference to the assembly (right-click in the Silverlight project, select Add Reference, find the assembly in the list on the .Net tab), and the proxy should now compile.

Hope this is helpful!
-Yavor Georgiev

What's new with web services in Silverlight 3 Beta

2009-03-20T13:18:00Z

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

Some new features for REST services

2009-03-13T20:04:00Z

Just a quick announcement here of a release that will be interesting to SL developers who want to access REST services. The WCF REST Starter Kit Preview 2 is now out, go grab it at http://msdn.com/wcf/rest. The release gives you a polished install/uninstall experience, so don't be afraid to try it on your box, it won't muck it up like "preview" software so frequently does.

This release gives you one interesting client-side feature that you may have heard me or Eugene speak about: Paste XML as Types. It's a VS menu item which helps you use XmlSerializer with REST services. Frequently these services use human-readable documentation to describe the XML shape, and it is difficult to hand-code a type to use with XmlSerializer, especially when the XML instance is complex. For example check out this sample XML response from the Yahoo BOSS API. With this new feature it takes one click to generate the type:

Another interesting feature in the release is HttpClient - a sort of specialized WebClient - which can be used to programmatically access REST services using an extensible model for sending HTTP requests and processing HTTP responses. The model enables you to complete common HTTP/REST development activities required to consume an existing service in a fraction of the time you normally spend. Some convenient time-savers include query string support (build URIs as name/value pairs) and serialization support (easily plug in types generated with Paste XML as Types to read the response).

Unfortunately in this release the starter kit only contains a .Net version of HttpClient, which will not compile in Silverlight. We are considering porting this prototype to Silverilght, and if you get a chance to try it on .Net, please let us know of any feedback you have.

Stay tuned for some exciting content coming out over the next week!

Cheers,
-Yavor

New Web Services Features in Silverlight 2 RTW

2008-10-20T16:39:00Z

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