Accessing SOAP Services

Silverlight 4 supports four binding configurations: two types of Request/Reply and two types of Duplex.

1. Request/Reply HTTP: a Windows Communication Foundation (WCF)-specific binding (the default)

   1. (Optional) Message credentials security

   2. Binary (the default) or Text encoding

   3. HTTP (the default)/HTTPS transport

2. Request/Reply HTTP: an interoperable binding that is not WCF-specific and can be configured with BasicHttpBinding

3. Duplex HTTP: WCF-specific binding that is configured with PollingDuplexHttpBinding

4. Duplex TCP: a WCF-specific binding for intranet use only

   1. Binary or Text encoding

   2. NetTcp transport

There are certain restrictions on the types of services that Silverlight 4 can access. If you are creating your WCF service without using the Silverlight-enabled WCF Service template, you must make sure that the WCF service is configured with the BasicHttpBinding for it to be supported. The PollingDuplexHttpBinding is also supported. For more information about using the duplex binding, see Building and Accessing Duplex Services.

Caution:
Note that other WCF bindings are not available because they require features that are not supported by the Silverlight 4 client. WSHttpBinding, for example, requires sessions and transactions, which are not supported.

Silverlight 4 supports most services that conform to the WS-I Basic Profile 1.0 (specifically, SOAP 1.1 over HTTP). SOAP 1.2 and WS-Addressing 1.0 are also supported. Additionally, a small subset of the WS-Security protocol is supported, namely, the ability to send username and password tokens in messages (without using message encryption or digital signatures). Most other Web service (WS-*) protocols are not supported. For Windows Communication Foundation (WCF) services, this means that they need to be configured to use either the BasicHttpBinding or the PollingDuplexHttpBinding, unless a CustomBinding is to be used. 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 and Binary encodings are supported in Silverlight, but the MTOM encoding is 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 by manipulating SOAP headers.

SOAP headers are supported via the OutgoingMessageHeaders and IncomingMessageHeaders properties inside an operation method call, or by writing custom WCF channels. Note that IncomingMessageHeaders are only available when you use the “Begin/End” asynchronous programming model to invoke operations.

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.

Finally, in addition to regular SOAP over HTTP, Silverlight 4 supports consuming SOAP services using the HTTP Polling Duplex protocol described in Duplex Services. For more information, see Building and Accessing Duplex Services.

Silverlight is a Web browser plug-in that leverages the Web browser for communicating over the network. There are two restrictions related 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, unless you switch to an alternative HTTP stack as described above. For more information about the security implications of this, see Additional 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.