Networking and Web Services in Silverlight

Getting Data into Silverlight

One way to determine the best networking and Web service technology that you should use is to examine the message pattern and interaction model required by your application. For this discussion, message patterns can be classified by considering the party that initiates the communication. At one end of the spectrum, the client initiates request/reply exchanges. At the other end, the server initiates the communication, as with multicast when it sends a message or streams media to a group of client applications. In the middle of the spectrum, there are various types of duplex communication where either the client or the server application can initiate the communication.

There also are a range of possible interaction models. A one end of this spectrum you have operation-centric interactions where parties to an exchange are considered to be objects which call operations on each other. SOAP is the paradigmatic protocol used in these Web services. At the other end of the spectrum you have data-centric interactions where the calls are typically limited to using create, retrieve, update, and delete (CRUD) operations with a database or other resource. REST is the paradigmatic architectural style used in these Web services.

Conceptually, you can visualize message patterns and interaction models in a grid. For example, you can put message patterns along the horizontal axis and interaction models along the vertical axis as shown in the following illustration.

The points on this illustration are characterized as follows.

Message Patterns

• Request/Reply
  In the request/reply message pattern, all communication is initiated by the client and the networked resource, typically a Web service, replies to these requests from the client. Clients make calls to service operations and wait for a response from the service. An example of the request/reply message pattern is a client requesting product information from a retail Web service.
• Duplex
  In the duplex message pattern either the client or server can initiate the communication and either endpoint can send messages to the other independently. The client connects to a service and provides the service with a channel on which the service can send messages back to the client. Examples of the duplex message pattern are a chat server or e-mail client.
  
  A Silverlight client is not addressable over HTTP because the browser environment does not allow the creation of an HTTP listener. HTTP duplex communication with a Silverlight client is achieved by having the client poll a destination server for messages from within an established session. Silverlight provides an HTTP polling duplex binding to provide a resilient and standards compliant duplex communication with a supporting client and proxy programming model.
• Multicast
  Multicast message pattern refers to the server sending the same message to any number of clients at the same time. It is a one-to-many communication. Examples of the multicast message pattern are video streaming or live market data streaming. Silverlight clients join the relevant multicast group to receive a streamed broadcast.

Interaction Models

• Operation-centric
  In an operation-centric interaction model, both the client and server are considered objects in memory, with in-memory state. The objects can then call operations on each other. An example of an operation-centric interaction model is a chat server.
• Resource-centric
  A resource-centric interaction model is a database or data model. Operations on this data typically consist of create, retrieve, update, or delete (CRUD) operations in the database. An example of a resource-centric interaction model is a client requesting data from a server by using a REST service.

Silverlight Networking Options

In Silverlight, there are many different ways to access Web services and other networked resources. Typically there is a method for requesting data from a Web service that is best suited to the operation the application needs to perform.

HTTP Classes

You can access Web services or resources on a network server directly from a Silverlight-based application using the HttpWebRequest/HttpWebResponse or WebClient classes in the System.Net namespace. These classes provide the functionality required to send requests to any Web service available over the HTTP protocol. Silverlight does not support the ability to host HTTP-based services, so these classes are useful when the Silverlight client is using an existing Web service. Typically, you would use these classes if the HTTP service is hosted by a third-party and not within your control. In this case, you need to make sure the requests match the exact format expected by the service. However if you are building the service yourself, Silverlight offers more productive end-to-end solutions, which can be built using the Windows Communication Foundation (WCF) described in more detail in the next section. For more information about HTTP security restrictions and accessing Web services using the WebClient or HttpWebRequest/HttpWebResponseclasses, see HTTP Communication and Security with Silverlight.

WCF Services

WCF services provide the foundation for building Web services for a Silverlight client application. If you control the data and the server hosting the data, the easiest way to expose it to Silverlight is by using a WCF service.

Depending on what you are trying to build, WCF offers three top-level programming models that you can choose from. Each model has its strengths and weaknesses, and it is up to you to choose which model your application fits before building your service. The following illustration shows the WCF architecture layers and the programming models available when using them. For more information about the WCF architecture, see Introducing Windows Communication Foundation in .NET Framework 4.

WCF core services are the most flexible kind of WCF services. They allow you to expose a class as a service and exchange objects between Silverlight and that service. In the Silverlight application, you can use tools such as Visual Studio, to generate a local proxy class for the remote service. This enables you to access the service as though it is a local class. WCF core services support a breadth of protocols (including HTTP and TCP) and a variety of formats, such as SOAP, XML, and Atom. For more information, see Building and Accessing Services using Generated Proxies.

WCF Data Services

Windows Communication Foundation (WCF) Data Services, formerly known as ADO.NET Data services, provides a framework for you to access data from your existing data model in the style of representational state transfer (REST) resources. WCF Data Services exposes data as an Open Data Protocol (OData) feed. In addition, if your Silverlight application is interacting with SharePoint, SharePoint 2010 exposes data as WCF Data Services. WCF Data Services handles all of the HTTP communication, serialization, and other tasks you traditionally have when you attempt to expose your data model as a service. This means Silverlight-based applications can access this data through the standard HTTP protocol to execute queries, and even to create, update, and delete data in a data service, either in the same domain or cross domain. For more information, see WCF Data Services (Silverlight).

WCF RIA Services

WCF RIA Services simplifies the development of n-tier solutions for the enterprise. RIA Services provides data modeling, validation, concurrency, security and authentication tools and services that enable you to easily create forms that display data from the underlying database in the application style sometimes referred to as “forms over data”. In addition, since RIA Services exposes server data as WCF services, you can leverage the WCF configuration tools. For more information, see WCF RIA Services.

Sockets and Multicast

Silverlight offers support for sockets-based communication with classes in the System.Net.Sockets namespace. The classes provide a mechanism for real-time duplex communication with remote network resources and enables higher-level APIs to communicate over a bi-directional transport. This also allows an application to interoperate as a client with existing TCP services. For more information, see Working with Sockets. In addition, Silverlight 4 added support for multicast messaging. Multicast messaging allows for a large receiver population and either a one-to-many or a many-to-many architecture. For more information see Working with Multicast.

Deciding Which Technology to Use

Once you know the requirements of your application, you can decide which technology is the best to use. The following table lists some scenarios and the recommended networking and Web services technology for implementing them, as well as links to topics that show you how to use that technology.

Related Topics

This article was originally published on the MSDN website. Reprinted with permission