Silverlight 2 supports most services that conform to the WS-I Basic Profile 1.0. Specifically, SOAP 1.1 over HTTP is supported. But other versions of SOAP and most other Web service (WS-*) protocols, such as WS-Addressing, are not supported. For Windows Communication Foundation (WCF) services, this means that they need to be configured to use the BasicHttpBinding. Note that the default binding for Windows Communication Foundation (WCF) services is often different. You need to ensure that you have at least one endpoint with the basicHttpBinding before a service can be consumed from a Silverlight client.

Textual XML encoding is supported in Silverlight, but MTOM or Binary encodings are not supported.

Some Web service protocols are not directly supported by Silverlight, but it is still possible to consume services that use these protocols by manually implementing the required protocol. For example, WS-Security is not directly supported, but the token-based authentication component of WS-Security can be emulated by injecting the appropriate SOAP headers into request messages.

SOAP headers are supported via the OutgoingMessageHeaders and IncomingMessageHeaders properties inside an operation method call.

Receiving SOAP faults is not supported due to Web browser limitations. When the service does send a fault, an exception is thrown on the client, but it does not specify any information about the fault that has occurred.

Finally, in addition to regular SOAP 1.1 over HTTP, Silverlight 2 supports consuming SOAP services using the HTTP Polling Duplex protocol described in Duplex Services. For more information, see Building and Accessing Duplex Services. These services cannot be consumed using generated proxies.

Cross-domain calls to SOAP services from Silverlight applications are subject to the same cross-domain restrictions that apply for any Silverlight applications. Such calls must be specifically enabled by the owner of the service adding an appropriate cross-domain policy. For procedures that describe how to do this for a service that you control, see Making a Service Available Across Domain Boundaries. If there are public services on the Internet or within your enterprise whose cross-domain policy you do not control, then you cannot consume them from a Silverlight client directly.

Silverlight is a Web browser plug-in that leverages the Web browser for communicating over the network. In addition to the lack of support for faults that has already been mentioned, there are several other restrictions due to the Web browser environment that should be noted.

Authentication information, including cookies, is managed by the Web browser. You cannot customize this information from your application code when you communicate with services. For more information about the security implications of this, see Security Considerations for Service Access.

The number of simultaneous open connections to the same URL domain is often limited by the browser. This is normally not an issue in most applications, but you need to be aware of this when dealing with Duplex communications. For more information, see Building and Accessing Duplex Services.

When using generated proxies in Silverlight to consume Web services based on the .NET Framework technologies (either Windows Communication Foundation (WCF) or ASP.NET Web Services), there are some additional considerations.

Services that use DataSet objects or typed DataSets that derive from a DataSet cannot be consumed from a Silverlight client. You can get access to the raw XML data that represents the DataSet, but using it is not recommended.

Certain complex .NET Framework types either do not exist in Silverlight, or exist but are not properly marked up for serialization, and so cannot be used in Web services. This applies mostly to types with the T:System.SerializableAttribute attribute that are neither collections nor enumerations. If you use such types in services, these services might be difficult to access from Silverlight, and will be especially difficult (and in some cases impossible) to access if some of the types implement the T:System.Runtime.Serialization.ISerializable interface. Do not rely on such types in your services.

Silverlight 2 also has the following temporary restriction. Services that specify custom SOAP headers in their WSDL are only partially supported. A proxy will be generated, but you will not be able to use the proxy to send or receive these headers.