Silverlight and WCF Feature Comparison

Microsoft Silverlight will reach end of support after October 2021. Learn more.

The Silverlight version 4 Web services stack and programming model are largely based on the client side of the Windows Communication Foundation (WCF). WCF server functionality for hosting Web services is not available in Silverlight 4. WCF client-side features are generally supported unless explicitly mentioned in this topic.

WCF Client Stack

There are several ways to use the WCF client stack to access a service.

It is used when invoking services through automatically generated proxies, as described in How to: Access a Service from Silverlight. The proxy must be generated in this procedure by using the Add Service Reference tool in Visual Studio 2010 for the Silverlight project.

Caution:
Proxies generated by using the WCF Svcutil.exe tool will not work in Silverlight 4. Use the SLsvcutil.exe tool instead. For more information about using this Silverlight tool, see Using SLsvcUtil.exe to Access a Service.

If you already have a Windows Communication Foundation (WCF) service contract definition, you can use the generic ChannelFactory class without having to generate a proxy. This might be the case, for example, if your client is sharing service definition code with the project on the server. In this case you could, for example, define a service contract interface IStockQuoteService and then use the same IStockQuoteService code in both the server and Silverlight projects. This would involve using a ChannelFactory<IStockQuoteService>. This advanced technique is demonstrated in How to: Call Operations Asynchronously Using a Channel Factory and in the Silverlight 4 context with Building and Accessing Duplex Services. For more information about defining and using service contracts, see Designing Service Contracts.

You can also use the WCF channel model directly to send arbitrary messages without any contract restrictions. This is the most complex and the most powerful approach. It is described in Client Channel-Level Programming.

Client-side extensibility is supported through the IClientMessageInspector, IClientMessageFormatter, and IParameterInspector classes. These extensibility points can be used to inspect and modify a message as it travels through the channels in the WCF stack. For example, IClientMessageFormatter can be used in a scenario where you want to attach a custom SOAP header (maybe some custom credential) to every outgoing message. For more information, see Extending Clients.

Regardless of which of these methods is used, only asynchronous operations are supported. Synchronous operations are not supported in Silverlight 4. For more information, see How to: Call WCF Service Operations Asynchronously and How to: Call Operations Asynchronously Using a Channel Factory.

When accessing one-way services from Silverlight, do not attempt to access the return value in the asynchronous callback method (for example, the AsyncCompletedEventArgs parameter in the case of generated proxies), or an exception will result.

Addresses and Bindings

When accessing a service by using one of the methods described in the previous section, the address and the binding of the remote service endpoint need to be specified. The address answers the question of “where” the service is located, while the binding answers the question of “how” to talk to the service. The answer to the “where” question is a URL. The answer to the “how” question is a list of which protocols to use when communicating with the service.

The address and binding can usually be specified either explicitly through code, or in the ServiceReferences.ClientConfig configuration file. For more information about using the configuration file, see Configuring Web Service Usage in Silverlight Clients.

WCF supports a variety of bindings, but in Silverlight 4 only the following bindings are supported:

• BasicHttpBinding: Uses SOAP 1.1 to communicate with the server. This is the correct binding to use for most service scenarios. It is the only binding supported by the Add Service Reference tool in Silverlight 4, and the only binding supported in the ServiceReferences.ClientConfig file. When using this binding, especially to interoperate with non-WCF SOAP services, consult the list of protocol restrictions provided in Accessing SOAP Services. SOAP faults are not supported, for example.

• PollingDuplexHttpBinding: Used to establish a duplex connection to a service, where the service can spontaneously send messages to the client. For more information, see Building and Accessing Duplex Services.

• CustomBinding: You can use binding elements provided in Silverlight to build a custom binding, or you or third-party vendors can build custom bindings. For more information, see Custom Bindings. Note that only the following binding elements are provided in Silverlight 4:

  • TextMessageEncodingBindingElement: This binding element supports the Textual encoding of XML. Only SOAP 1.1 is supported. WS-Addressing and MTOM are not supported. For more information, see the Supported Protocols section in Accessing SOAP Services.

  • BinaryMessageEncodingBindingElement: This binding element supports the .NET Binary Format for XML used to encode messages.

  • HttpTransportBindingElement and HttpsTransportBindingElement: HTTP and HTTPS support. For more information, see the HTTP Considerations section in Accessing SOAP Services.

  • PollingDuplexBindingElement: This binding element is used to establish a duplex connection to a service. For more information, see Building and Accessing Duplex Services.

  • TcpTransportBindingElement: This binding element supports using the TCP transport with a duplex connection.

  • SecurityBindingElement: This binding element supports using SOAP message security. In Silverlight 4, passing username and password as SOAP headers is supported.

  • MessageEncodingBindingElement, TransportBindingElement, ConnectionOrientedTransportBindingElement, and BindingElement: These binding elements are provided to support extensibility. For example, you can create a binding element that results in a channel stack that injects a particular SOAP header into every outgoing request. For more information, see Extending the Channel Layer.

More advanced bindings and binding elements, such as the ones dealing with queues, reliable sessions, transactions, message-level security (such as WS-Security), peer-to-peer messaging, and transports other than HTTP, HTTPS, and TCP are not provided in Silverlight 4.

No analog to the System.ServiceModel.WebHttpBinding that is provided in WCF is provided in Silverlight 4. To access pure HTTP, REST, RSS/Atom, or AJAX services from Silverlight 4, use the techniques described in Accessing HTTP and REST-Based Services Directly, such as the System.Net.WebClient class. To access ASP.NET AJAX services, see Accessing ASP.NET AJAX Services.

Data Transfer and Serialization

In a connected system, services and clients depend on the exchange of data to accomplish any task. This data can be sent over the network in various formats, such as XML or JSON, and translated from or to various .NET Framework types when it is sent or received. This process is called serialization or deserialization, and is described in detail in Data Transfer and Serialization.

Serialization support in Silverlight 4 is based largely on WCF serialization technologies. But there are some differences described in the following sections that developers of Silverlight applications should understand.

When using the WCF channel stack as described in the preceding section to access services, only XML is used as a data format, using either the DataContractSerializer or the XmlSerializer (described in the following section). However, there are other uses for serializers in Silverlight, where the rules governing serializability are different:

• The DataContractSerializer (and hence the XML format) is used when you store objects in the Silverlight Isolated Storage.

• The DataContractJsonSerializer (and hence the JSON format) is used for several aspects of communication between the Silverlight controls and the hosting HTML page, such as when using the ScriptObject class.

• You can also use the serializers directly to produce and parse XML or JSON data. This is often useful when working with HTTP/REST services, as described in Working with XML Data and Working with JSON Data.

Data Contract Serialization

The DataContractSerializer (for XML) and DataContractJsonSerializer (for JSON) are the primary serializers in Silverlight 4, and can work with almost any .NET Framework type. For public types that are not otherwise marked, all public fields and properties will be serialized to XML or JSON, respectively. Most collection types will result in XML or JSON arrays. To customize serialization, such as to change XML element names, you can use DataContractAttribute, DataMemberAttribute, CollectionDataContractAttribute, and others. For a full list of supported types and serialization rules, see Types Supported by the Data Contract Serializer, Using Data Contracts, and Support for JSON and Other Data Transfer Formats.

The following important distinctions exist between Silverlight 4 and WCF:

• Normally, serializers can use only public types and public members. This is equivalent to WCF behavior in Partial Trust mode. There is, however, one exception: internal types and internal members can be used, if the assembly that contains the types uses the InternalsVisibleToAttribute (in the Silverlight mscorlib.dll) to allow access to the System.Runtime.Serialization.dll and System.ServiceModel.Web.dll assemblies.

• The WCF type System.Runtime.Serialization.IExtensibleDataObject interface is not supported in Silverlight 4.

• Many built-in .NET Framework types are serializable in WCF because they have the System.SerializableAttribute applied. This mechanism does not exist in Silverlight 4, and thus many such types are either not serializable, or are not serializable in a way that is compatible with WCF. For this reason, these types cannot be reused in generated proxies. For example, if a service returns the System.Net.IPAddress type, a Silverlight client proxy generated by using Add Service Reference will not use this type, even though it is present in Silverlight and even though type reuse is enabled through the Advanced dialog box in the tool. Instead, a new type will be generated.

• When generating collection types, the Silverlight 4 version of the Add Service Reference tool defaults to generating ObservableCollection to make it easier to bind the results of a Web service call to user interface components. This can be changed in the Advanced dialog box.

• The following are also not supported in Silverlight 4: System.Runtime.Serialization.NetDataContractSerializer, Schema Import/Export, deserialization with a maximum objects quota, and the legacy .NET Framework 3.0 object reference mechanism (although the newer interoperable object reference mechanism as described in Interoperable Object References is fully supported).

• In WCF, the DataContractJsonSerializer can serialize and deserialize by using a special mapping between JSON and XML as described in Mapping Between JSON and XML. In Silverlight 4, the DataContractJsonSerializer does not support this mapping, but the mapping itself is supported in Silverlight 4 through the JsonReaderWriterFactory class in the System.Runtime.Serialization.Json.dll assembly in the Silverlight 4 SDK. This is useful in advanced scenarios where objects must be able to be represented as both JSON and XML and the type of these objects is not known in advance.

• In general, services that use types that implement ISerializable in .NET Framework will not be usable from Silverlight. The Add Service Reference tool may generate a proxy for such services, but the proxy will not be usable.

XmlSerializer

Often, the DataContractSerializer is not sufficient to express more complex XML or XML Schema structures (such as XML attributes, or the concept of a choice between multiple XML elements). These cases frequently arise when interoperating with non-WCF SOAP services, or third-party HTTP/REST services that use more complex XML. For such cases, Silverlight 4 supports the XmlSerializer. In general, if you know that the XML you are producing or consuming must conform to some predetermined form that is outside of your control, the XmlSerializer is usually the right serializer to use. Be aware that using the XmlSerializer adds to the size of your Silverlight XAP application package.

The XmlSerializer is automatically selected by the Add Service Reference tool when the service that you are referencing requires it—there is no action required on your part.

The XmlSerializer support in WCF is described in Using the XmlSerializer Class and XML and SOAP Serialization.

In Silverlight 4, generating SOAP messages as described in the preceding document is not supported.

Using Message Contracts

Message contracts are supported in Silverlight 4. The equivalent WCF feature is described in Using Message Contracts.

However, there is no SOAP Header support in message contracts. If headers are described in WSDL, they will not be generated by the Add Service Reference tool. Headers are still supported in Silverlight 4 through the OperationContext class (IncomingMessageHeaders / OutgoingMessageHeaders properties).

Metadata

• Silverlight 4 supports a subset of WSDL 1.1 and Xml Schema. Other metadata formats are not supported at this time.

• Programmatic WSDL import or export is not supported.

• The Windows Communication Foundation (WCF) Svcutil.exe tool cannot be used to download metadata and generate Silverlight client code. Instead, use the Add Service Reference feature in Visual Studio 2010.

Syndication

Syndication support in Silverlight is enabled by referencing the types in the System.ServiceModel.Syndication.dll extension assembly.

Syndication support in Silverlight 4 is based largely on the WCF syndication object model. The following WCF resources provide an in-depth description of the WCF syndication feature set:

• WCF Syndication Overview

• Architecture of Syndication

• How the WCF Syndication Object Model Maps to Atom and RSS

• Syndication Extensibility

Silverlight exposes a subset of the WCF syndication object model, and the scenarios targeted by the Silverlight and WCF platforms are not the same. WCF includes support for creating Web services that expose data as syndication feeds. Silverlight is a client technology that supports accessing existing feeds from a browser-based application. When reading the preceding articles, some parts of them are irrelevant in the context of Silverlight.

Two main client syndication scenarios are enabled in this Silverlight 4 release:

• Deserializing (parsing) an RSS or Atom feed obtained through an HTTP request into the SyndicationFeed class.

• Serializing an instance of the SyndicationFeed class into an RSS or Atom feed and sending it through HTTP.

Ajax Integration and JSON Support

The only features supported by Silverlight 4 are listed below:

• JSON serialization using DataContractJsonSerializer.

• Using JsonReaderWriterFactory in the System.Runtime.Serialization.Json.dll extension assembly to generate reader classes over data encoded with JSON from a stream or buffer and map it to an XML Infoset, and to generate writer classes to map an XML Infoset to JSON and write JSON-encoded data to a stream.