Never trust that your data source will return pure, clean data every time. It's possible that, either purposefully or as a result of an error on the part of the service creator, harmful data may be returned to your application. You should always take steps to validate that the data you receive is compatible with the use you intend.

Any time you're passing sensitive data, you should use Hypertext Transfer Protocol over Secure Sockets Layer (HTTPS), which encrypts the message to prevent eavesdropping. In order to access cross-scheme services and data (HTTP to HTTPS or HTTPS to HTTP), the cross-domain policy file must permit that access.

Because Silverlight typically uses the browser's networking stack, cookies for the current domain also get added to requests from your Silverlight application. This is good if you're hosting your Silverlight component in an authenticated application that uses tokens stored in a cookie. In this case, the token also authenticates the requests originating from your Silverlight application, ensuring that you can access the resources you're authorized for.

One potential problem using this method is that when a user has a cookie-based token for a given domain, any Silverlight request to that domain contains the auth cookie, even if the request is from a different Silverlight application than the one you intend. Another issue is that this method of authentication relies on the client browser having session cookies enabled—which isn't always true.

Trust and security are important for any application; before we move on to the meat of accessing data, let's make sure the browser itself is capable of doing everything you're asking of it. This question brings us to the next basic concept: limitations of the browser.

The number of concurrent connections to a single subdomain (for example, http://10rem.net and http://images.10rem.net are two different subdomains) is limited in most browsers to two. This limit has been increased in Internet Explorer 8 to six concurrent connections; but because Silverlight runs in multiple browsers, you should still be aware of it. Because Silverlight uses the browser's networking stack for its communications by default, it's bound by the same limits. You may need a combination of resources or other approaches to ensure that this doesn't create unnecessary delays in your application. Keep in mind that the browser may be loading objects outside the scope of the Silverlight application as well, such as stylesheets, images, and JavaScript files. All these objects count toward the limit of two concurrent connections. You should keep this fact in mind, particularly when performing duplex communication as described in section 14.4.

All communication from within the Silverlight application is done asynchronously because of the Silverlight development team's decision to use the browser's networking API, and to keep the APIs tight with only one way to accomplish any given task. The most common way of making asynchronous calls requires a few simple steps, which we'll detail in the following section. Typically, all you need to do is create an event handler to be executed when the call returns.

If you want to create a more synchronous experience for your application, you can enable some kind of blocking element, such as a download-progress animation, when the call begins and then remove it once the request has returned its data. We'll discuss how to create animations in chapter 22.

Note that the asynchronous behavior can occur on multiple threads, a fact that can cause trouble when you aren't aware of it. In section 14.2.2, we'll point out where you need to be careful with which thread you're on, and show you a technique to avoid trouble. Now that we have the basics out of the way, let's get to the point of this chapter: connecting to data sources.

The easiest way to connect to a service is through a service reference proxy. If the web service you're connecting to supports Web Services Description Language (WSDL), Visual Studio can read that information and create a proxy in your application for you. Creating a service reference in your Silverlight application takes three simple steps:

When the service reference is created, Visual Studio also adds references to the System.Runtime.Serialization and System.ServiceModel assemblies. These are used by Silverlight in connecting to web services and in serializing and deserializing the SOAP message.

When you've created your service reference, it's easy to use for both sending and receiving data. First, let's talk about calling SOAP services using the service reference you just created.

Connecting to and downloading data from a simple SOAP service is easy. You need to add two Using statements to your page, one for System.ServiceModel and another for System.ServiceModel.Channels. Next, you need to create a proxy to the service using the service reference as created in the previous section. Name the service reference namespace SilverService for this example. Then, you add an event handler to catch the return of the asynchronous call to the exposed method on the service. These steps are demonstrated in listing 14.1.

Example 14.1. Calling a SOAP service

This shows the entire process of creating the proxy , adding an event handler , calling an asynchronous method , and handling the results . In this example, the SOAP service you're connecting to exposes a method called GetTime, which accepts no input properties and outputs a DateTime of the current time. You first create a Binding of type BasicHttpBinding. This tells the proxy that the service you're connecting to uses SOAP 1.1. The default constructor for BasicHttpBinding creates a Binding with no security. An optional parameter on the constructor accepts a BasicHttpSecurityMode, which allows you to tell the binding how to secure itself; for example, you can tell the binding to use SSL when transmitting the SOAP message. You also create an EndpointAddress that points to the URI of the service you're about to call. Finally, you create the proxy using the service reference created earlier and pass into it the binding BasicHttpBinding and the initialized EndpointAddress objects.

Next, you need to add an event handler to be called when your asynchronous method call returns. You can do this by using the Visual Studio shortcut of pressing the + key, then the = key, and then pressing Tab twice after selecting the GetTimeCompleted event on your proxy. Using this shortcut automatically finishes the event handler declaration for you and creates a stubbed method as the event handler. Finally, you call the Get-TimeAsync() method on the proxy to begin the asynchronous call to the service. IntelliSense will show you a [webmethod]Completed event and a [webmethod]Async() method for each method exposed by the SOAP service. When you created the service reference in the previous step, Visual Studio queried the service to see what methods were available and made proxy methods for each of them.

After the service returns, the method declared as the event handler-proxy_GetTimeCompleted-gets called with the results. Because the method is outputting the results as a Datetime object, you can convert it to a string using standard .NET conversion methods, which you can then assign to the Text property of a TextBlock. The only other task to perform in the return method is to close out the connection using the CloseAsync() method on the proxy. Garbage collection will technically come through and close any old connections, but it's good programming practice to close any connection when you're done using it.

And that's all there is to it—you've now connected to a SOAP service, called a method on it, and displayed the results. Sending data to a SOAP service is just as easy.

If you're thinking that all you need to do to send data to a SOAP service using a service reference is to include a parameter in the method call, you're right. Let's look at listing 14.2 for an example.

Example 14.2. Sending data to a SOAP service

Listing 14.2 builds on the code from listing 14.1. This is an example of sending of a single int as a parameter to the GetCoolText method on the web service. This approach is fine for sending a simple data value, but what about complex data types? Still no problem.

Sending and receiving complex data types over a SOAP service is also a simple matter. When you created the service reference, the signatures for objects used in the SOAP message were automatically analyzed and a client-side proxy made for those as well. With this proxy, you can instantiate objects of that type in your application (see listing 14.3).

[WebMethod]
public void SetSomething(int count, WsUser myObject)
{
  //Perform database operations here
}

...
public class WsUser
{
  public int Id { get; set; }
  public string Name { get; set; }
  public bool IsValid { get; set; }
}

private void UploadUser()
{
  Binding myBinding = new BasicHttpBinding();

  EndpointAddress myEndpoint =
    new EndpointAddress("http://localhost:55905/SampleAsmx.asmx");
  SilverService.SampleAsmxSoapClient proxy = new
    SilverService.SampleAsmxSoapClient(myBinding, myEndpoint);

  SilverService.WsUser myData = new
    SilverService.WsUser()
    { Id = 3, Name = "John", IsValid = true };

  proxy.SetSomethingCompleted += new
    EventHandler<System.ComponentModel.AsyncCompletedEventArgs>
    (proxy_SetSomethingCompleted);

  proxy.SetSomethingAsync(1, myData);
}
void proxy_SetSomethingCompleted(object sender,
  System.ComponentModel.AsyncCompletedEventArgs e)
{
  (sender as SilverService.SampleAsmxSoapClient).CloseAsync();
}

This listing shows how you can use complex data types on SOAP services from within your Silverlight application. The service itself is left as an exercise for you, and the example is illustrative only. As you can see in the web method declaration, the method SetSomething expects two parameters: an int and a WsUser. WsUser is made up of three properties. Note that both the web method and the WsUser class are part of the ASMX web service, not the Silverlight application.

Now, let's use WsUser in the example application. Because WsUser is a return type on a method, a copy of its type exists on the proxy for you to use. In this example, you create an instance of the WsUser class and fill its properties. Then, you add the instance of the object as a parameter on the asynchronous method call, SetSomethingAsync.

So far, we've shown the slightly more verbose way of calling a service, where all the endpoint information is handled in code. Silverlight provides another option: you can use the information in the ServiceReferences.ClientConfig file.

An example configuration file is shown in listing 14.4. The configuration file specifies, among other things, the type of encoding, the maximum receive message and buffer sizes, the binding contract, and endpoint information.

Example 14.4. The ServiceReferences.ClientConfig file

Although certainly not a requirement, this example uses the new WCF binary encoding with a WCF SOAP service on the server-a new feature enabled by default in Silverlight when using the Silverlight Enabled WCF Service template mentioned in section 14.5.1. This reduces the message size considerably in situations where the server and client aren't using GZIP compression on the content and the server is running .NET 3.5 SP1 or above.

In addition, the server side is able to handle more requests due to the binary nature of the messages. The downside is that the service clients are restricted to those aware of the proprietary format, unless you add a second endpoint.

<grant-to>
  <socket-resource port="4502-4534" protocol="tcp" />
</grant-to>

http://<IpAddressOfYourNetTcpService>:80/clientaccesspolicy.xml

When using the information from the .ClientConfig file and eliminating all the setup code, your client-side code becomes considerably simpler, as shown in listing 14.5.

Example 14.5. Client-side code using ServiceReferences.ClientConfig file

The code has been simplified considerably because you externalize the settings. This time around, you don't need to create bindings or endpoints and pass them in to the proxy. Whether this is appropriate for your situations comes down to whether you want to handle the bindings in code or in configuration files.

In code, you can get the address of the current server and base your service call on that, if appropriate. But if you want to change that algorithm and, say, move from www.mydomain.com/services to api.mydomain.com, you'll need to change code and recompile/redeploy the client.

In configuration, you can set the URL to be anything you wish, but you must remember to change it when moving between servers (such as from development to test to staging to production). Given that this doesn't require a recompile and the format is XML inside a standard zip, there's little risk to this approach.

private void CallService_Click(
             object sender, RoutedEventArgs e)
{
  var client = new HelloWorldServiceClient();
  client.HelloWorldCompleted += (s, ea) =>
  {
      Results.Text = ea.Result;
  };
  client.HelloWorldAsync();
}

That's all it takes to use SOAP services in Silverlight. Silverlight isn't limited to SOAP services. Next, we'll discuss consuming REST services through Silverlight, a topic that opens up a whole new arena of data providers.

The asynchronous nature of Silverlight web service calls can create threading problems for the developer. When you're dealing with service reference-generated proxies, threading isn't an issue; when you're creating the connection yourself, you have to deal with this part as well. When you attempt to access UI elements directly within callback methods, you get a threading exception. You deal with this by creating a class-level variable of type SynchronizationContext, which gives you a handle back to the correct thread to do UI updates:

private SynchronizationContext UIThread;
private void btnSingleXml_Click(object sender, RoutedEventArgs e)
{
  UIThread = SynchronizationContext.Current;
  ...
  request.BeginGetResponse(SingleXmlCallBack, request);
}
private void SingleXmlCallBack(IAsyncResult result)
{
  ...
  UIThread.Post(UpdateUiText, responseStream);
}
private void UpdateUiText(object stream)
{
  ...
}

The first thing you do in this example is create a class variable of type SynchronizationContext. Scoping it at the class level means you'll have access to it no matter where you are in the process. Next, in the method that starts the request (we'll detail the request in the next section), you assign a reference to the current thread to the variable previously created. Then, in the callback method, you call the Post method on the SynchronizationContext variable, which has two parameters. The first parameter accepts a method to do the UI update with, and the second accepts an object. In this case, it's simplest to send the entire response stream as the second parameter. Finally, in the method called by the Post method, you can cast the received object into a Stream and perform whatever UI updates you need. You don't need to pass the entire response stream to the method that updates the UI—you can send any object. It's my personal preference to let the update method also do any deserialization; by using this technique, you ensure that your UI updates will succeed.

As you can see, as long as you know how to get back to the UI thread, there isn't a problem here. Now, let's GET to the meat of REST services.

In relation to Silverlight, although REST may dictate the method in which a resource is accessed, it doesn't dictate the format of the data received. The most common ways to return data from a RESTful web service are Plain Old XML (POX) and JSON. We'll discuss how to consume both POX and JSON in section 14.3.

The basics of calling a REST-based web service from Silverlight involve creating an HttpWebRequest object, setting its destination URI, and calling it asynchronously (see listing 14.6).

private void GetSingleXml_Click(object sender, RoutedEventArgs e)
{
  UIThread = SynchronizationContext.Current;
  string rawPath
    = "http://www.silverlightinaction.com/Authors.svc/SingleXml/{0}";
  Uri path = new Uri(string.Format(rawPath, Input.Text),
    UriKind.Absolute);

  HttpWebRequest request = (HttpWebRequest)WebRequest.Create(path);
  request.BeginGetResponse(SingleXmlCallBack, request);
}
private void SingleXmlCallBack(IAsyncResult result)
{
  HttpWebRequest request = (HttpWebRequest)result.AsyncState;
  HttpWebResponse response
    = (HttpWebResponse)request.EndGetResponse(result);
  Stream responseStream = response.GetResponseStream();
  UIThread.Post(UpdateUiText, responseStream);
}

In this example, you make a simple request to a RESTful web service. Three steps are necessary when making a GET request, all of which are demonstrated here:

The BeginGetResponse method initiates the call to the service and registers the passed-in method as a callback method. When the response returns, that method will be called with the current HttpWebRequest being passed to it as type IAsyncResult.

In the callback method, the first thing is to cast the AsyncState of the IAsyncResult into an HttpWebRequest object. In the next statement, you call the EndGetResponse method on the request object to both end the connection and return an HttpWebResponse object. Finally, you call the GetResponseStream method of the HttpWebResponse object to get the Stream, the response to your web service call. We'll cover deserializing the Stream into useful data in section 14.3.

Most RESTful services use GET to retrieve data and POST to send it. Because the default HTTP verb used when using HttpWebRequest is GET, you need to do a few things differently when you want to perform a POST. Listing 14.7 shows the process of sending data to a REST service.

private void Test_Click(object sender, RoutedEventArgs e)
{
  UIThread = SynchronizationContext.Current;
  Uri path = new
    Uri("http://www.silverlightinaction.com/Authors.svc/Update/Brown",
    UriKind.Absolute);
  HttpWebRequest request = (HttpWebRequest)WebRequest.Create(path);
  request.Method = "POST";
  request.ContentType = "application/xml";
  request.BeginGetRequestStream(AddPayload, request);
}

private void AddPayload(IAsyncResult result)
{
  HttpWebRequest request = (HttpWebRequest) result.AsyncState;
  StreamWriter dataWriter =
    new StreamWriter(request.EndGetRequestStream(result));
  dataWriter.Write("<?xml version="1.0"?><Author><FirstName>Bob" +
    "</FirstName><LastName>Smith</LastName></Author>");
  dataWriter.Close();
  request.BeginGetResponse(SingleJsonCallBack, request);
}

private void SingleJsonCallBack(IAsyncResult result)
{
  HttpWebRequest request = (HttpWebRequest)result.AsyncState;
  HttpWebResponse response =
    (HttpWebResponse)request.EndGetResponse(result);
  Stream responseStream = response.GetResponseStream();
  UIThread.Post(UpdateUiText, responseStream);
}

Because REST services don't have methods, and instead deal with entities, you need to add any data to be sent to the service to the message being sent. In listing 14.7, instead of calling BeginGetResponse from the initial call, you call BeginGetRequestStream. This event handler allows you to add information to the stream after it's created but before it's sent to the service. After that's been done, you register the BeginGetResponse event handler as is done during GET operations.

Knowing how to do GETs and POSTs is only half of the battle; you need to be able to use what gets returned as well. REST services normally return either XML- or JSON-formatted data. In section 14.4, we'll talk about ways to take the response stream containing these common data formats and convert it into useful objects.

The browser stack only allows POST and GET, not DELETE or PUT. Those limitations, and the need for out-of-browser networking support, prompted the team to create a second separate networking stack: the client HTTP Stack.

The HTTP Referer header is a web standard used to indicate the origin of a request. Often, this is used to figure out what other pages are linked to your page, or what other pages are attempting to post to your form.

When using the client stack, Silverlight automatically sets the HTTP Referer to the base URL of the .xap file where the out-of-browser application originated. This is useful, because an out-of-browser application doesn't really have a URL and certainly doesn't have a hosting web page.

For example, if I access my web site from a trusted out-of-browser application (remember, in trusted applications, there's no check for a client access policy), the request headers look like this:

GET http://10rem.net/ HTTP/1.1
Accept: */*
Accept-Language: en-US
Referer: http://localhost:21597/ClientBin/RefererTest.xap
Accept-Encoding: identity
User-Agent: ...
Host: 10rem.net
Connection: Keep-Alive

I removed the user-agent for brevity; it's the same as the previous example. But note the value of the HTTP Referer header. I ran this example from Visual Studio, so the host is localhost:21597. The full path of the .xap is included as the Referer automatically.

You can't manually set the HTTP Referer header; it's one of a number of restricted headers. In addition to the Referer, Silverlight also sets headers such as the Content-Length, User-Agent, and others. Some of those, such as Content-Length, Content-Type, and Authentication, have dedicated request properties that map to the appropriate headers. It's unusual to change Content-Length and Content-Type, but setting authentication credentials is a must for any serious web application.

Each example that follows uses the same Silverlight application and the same web service call. First, we'll show you what you're getting and then how to deal with it. Listing 14.10 shows how to use a latitude/longitude service to get the name for a location.

Example 14.10. Getting the XML from a latitude/longitude geo service

In listing 14.10, you use the HttpWebRequest object to retrieve the response stream from a web service that returns POX. The following examples show different versions of the UpdateUiText method, one for each way of parsing POX.

XLINQ is a flavor of LINQ used to navigate and parse XML content. It facilitates both property and query syntax to access the nodes and attributes in a chunk of XML. Add a reference to System.Xml.Linq, and then add the following to the code-behind:

public void UpdateUiText(object stream)
{
  XmlReader responseReader = XmlReader.Create((Stream)stream);
  XElement xmlResponse = XElement.Load(responseReader);
  XElement root = xmlResponse.Element("neighbourhood");
  Results.Text = root.ToString();
  City.Text = (string)root.Element("city");
  Name.Text = (string)root.Element("name");
}

This example shows the LINQ to XML version of UpdateUiText. It shows how using XLINQ to access the data contained within individual XML elements is incredibly simple. The first step is to create an XmlReader from the response stream. You can load that into an XElement, which represents the root element. You can then access any element or attribute by name to get its value.

This is a simple example of LINQ to XML, but it can be even more powerful when used to parse larger XML structures using the query syntax. Next, let's look at using the XmlReader directly.

It's possible to use the XmlReader itself, without using a higher-level object to parse the XML for you:

public void UpdateUiText(object stream)
{
  XmlReader responseReader = XmlReader.Create((Stream)stream);
  responseReader.Read();
  responseReader.ReadToFollowing("city");
  string city = responseReader.ReadElementContentAsString();
  responseReader.ReadToFollowing("name");
  string name = responseReader.ReadElementContentAsString();
  responseReader.ReadEndElement();
  responseReader.ReadEndElement();
  City.Text = city;
  Name.Text = name;
}

This example uses the plain XmlReader to step through the returned XML to find the values you want. The approach is rather clunky but does work. Because the XmlReader is forward-only, you have to be careful to get everything you need from the information the first time through-a potentially cumbersome task on complex documents.

In the next example, you can also see the same results using the XmlSerializer from the System.Xml.Serialization namespace, which is included in the SDK, so you need to add a reference to use it in your application.

The XmlSerializer provides a way to convert an XmlReader into strongly typed objects. This approach takes a little more setup but is incredibly useful in many business applications. Listing 14.11 shows how to use the XmlSerializer to parse an XML document.

Example 14.11. Using the XmlSerializer to parse an XML document

You can see in listing 14.11 that using an XmlSerializer allows you to create a strongly typed object from the incoming XML data. To use this approach, you need to define a class that matches the format of the incoming XML. This class can be defined in your application, in a referenced class library, or in a service reference proxy. The first step is to move your XmlReader to the correct location. You also need to create a new XmlSerializer and initialize it with the target type you want the XML deserialized into. The final step is to use the Deserialize method on the XmlSerializer instance you just created and pass in the XmlReader. The Deserialize method returns an object of the type it's defined as or, if the deserialization failed, null.

Now that you've seen how to use POX, let's look at another common data format. In the next section, you'll learn how to use JSON-formatted data. JSON can be returned from a RESTful service just as easily as XML can, so let's dig into that format now.

As with XML, there's more than one way to use JSON-formatted data returned from a web service. The JSON being deserialized in these examples is shown in the previous example. The ways of working with JSON data differ greatly, as the following examples will show:

public void UpdateUiText(Object stream)
{
  JsonObject nh = (JsonObject)JsonObject.Load((Stream)stream);
  City.Text = nh["neighbourhood"]["city"];
  Name.Text = nh["neighbourhood"]["name"];
  Results.Text = nh.ToString();
}

One way to read JSON data is by using JsonObject.Load to convert the stream into an object based on the structure found within the stream. To get access to the JsonObject, you need to add a reference to the System.Json assembly and add a Using statement for the same namespace to the page. After the JsonObject has been created, it's a matter of using the name of the property you want as the key. If the property is nested, you add more keys, as when accessing the city property inside the Neighbourhood class.

Another way to access returned JSON involves using the DataContractJsonSerializer to deserialize the stream into objects of predefined types. This new object to serialize and deserialize JSON is included in the System.Runtime.Serialization.Json namespace and in the System.ServiceModel.Web assembly. The two methods of the DataContractJsonSerializer are ReadObject and WriteObject, which deserialize and serialize JSON objects respectively.

The following example again uses the Neighbourhood class defined earlier:

public class MyResults
{
  public Neighbourhood neighbourhood { get; set; }
}
...
public void UpdateUiText(Object stream)
{
  DataContractJsonSerializer ser =
    new DataContractJsonSerializer(typeof(MyResults));
  MyResults nh = (MyResults)ser.ReadObject((Stream)stream);
  City.Text = nh.neighbourhood.city;
  Name.Text = nh.neighbourhood.name;
}

This example shows the classes that hold the data after it's deserialized, as well as the method that does the work. This approach is simple. First, you instantiate the DataContractJsonSerializer with the type of object you want filled. All that's left is to pass the response stream into the ReadObject method of the DataContractJsonSerializer you just created. You access the data as you would with any other strongly typed .NET object. In the case of two well-known schemas, RSS and Atom, there's no need to deserialize the stream yourself. We'll look at these specialized classes, which make consuming published feeds easy and straightforward.

One of the nice things about WCF is the ability to throw exceptions on a service call. Unfortunately, Silverlight doesn't support this. Any exception thrown by the service gets translated by the browser into a 404 File Not Found error. The creator of the WCF service can still add error messages by adding them as an OUT parameter.

When the signature of the WCF service contains an OUT parameter, you can access it directly through the EventArgs on the event handler for the completed call, as shown in listing 14.12.

[OperationContract]
string GetSomeData(int Id, out MyErrorObject myError);

void serviceProxy_GetSomeDataCompleted(object sender,
  GetSomeDataCompletedEventArgs e)
{
  if (e.Error != null)
  {
    Message.Text = e.Error.Message;
  }
  if (e.myError != null)
  {
    Message.Text = e.myError.Message;
  }
  else
  {
    Message.Text = e.Result.ToString();
  }
}

In this example, you see a standard [ServiceMethod]Completed method like those shown throughout this chapter. This example also demonstrates error trapping and a custom out parameter.

Now that you've seen standard WCF services, let's dig deeper and look at how WCF duplex services can enable you to push data from a server to Silverlight.

See the source code at Manning.com for everything required to set up a polling duplex service in a web project. When you have a functioning WCF service set up to enable duplex communication, let's attach it to a Silverlight application. In the test application, a Button initiates the duplex communication and a TextBlock displays the results, so the XAML is simple. Here, you're building a simple application that registers with the service to get updates on scores from a game (see listing 14.13).

Example 14.13. Sample application to get score updates

The only thing of note in the XAML is that the Click attribute of the button points to the GetScores_Click method, which we'll discuss in listing 14.14. In this example, you grab a link to the current SynchronizationContext before beginning your asynchronous operations. This ensures that you always have a way to update the user interface.

Example 14.14. Creating the polling duplex client

In this example, you start the process of binding to a duplex web service. You begin by creating a PollingDuplexHttpBinding object, on which you set the timeout properties. You then use that polling object to create an IChannelFactory of type IDuplex-SessionChannel. The next step is to begin the asynchronous call using the BeginOpen method of the factory you just created.

The PollingDuplexHttpBinding constructor accepts an optional parameter that allows you to specify either single messages per poll or multiple messages per poll. If you want to support HTTP message chunking-multiple messages per poll-you can pass the parameter in to the constructor like this:

var poll = PollingDuplexHttpBinding(
              PollingDuplexMode.MultipleMessagesPerPoll);

Using the multiple messages option can significantly reduce the round trips for services that typically have more than one message waiting in response to a poll, allowing the service to scale better.

One thing you'll see throughout these samples is the calling of CompletedSynchronously immediately after the asynchronous call. You do this in case the response is immediate, as can occur for some small asynchronous operations. With this in mind, note that all the asynchronous calls are to methods that also check the CompletedSynchronously property and then either return or call the proper next method. Here's an example of one such method:

void OnOpenFactoryComplete(IAsyncResult result)
{
  if (result.CompletedSynchronously)
    return;
  else
    OpenTheChannel(result);
}

For the rest of this sample, we won't show the On[action]Completed methods, because they all follow the pattern of this example. The next step is to open the channel with the WCF service and to begin polling it for queued messages, as in listing 14.15.

void OpenTheChannel(IAsyncResult result)
{

  IChannelFactory<IDuplexSessionChannel> channelFactory =
    (IChannelFactory<IDuplexSessionChannel>)result.AsyncState;

  channelFactory.EndOpen(result);

  IDuplexSessionChannel channel = channelFactory.CreateChannel(new
    EndpointAddress("http://localhost:51236/ScoreService.svc"));

  IAsyncResult channelOpenResult = channel.BeginOpen(new
    AsyncCallback(OnOpenChannelComplete), channel);

  if (channelOpenResult.CompletedSynchronously)
  {
    StartPolling(channelOpenResult);
  }
}

void StartPolling(IAsyncResult result)
{
  IDuplexSessionChannel channel =
    (IDuplexSessionChannel)result.AsyncState;
  channel.EndOpen(result);

  Message message =
    Message.CreateMessage(channel.GetProperty<MessageVersion>(),
    "Silverlight/IScoreService/Register","Baseball");

  IAsyncResult resultChannel = channel.BeginSend(message,
    new AsyncCallback(OnSendComplete), channel);

  if (resultChannel.CompletedSynchronously)
  {
    CompleteOnSend(resultChannel);
  }
  PollingLoop(channel);
}

The method OpenTheChannel in this code shows where you define the service you're attempting to connect to. It's assigned as an endpoint on the duplex channel. The StartPolling method creates the SOAP message for the initial call and sends it to the service.

Listing 14.16 shows that CompleteOnSend receives the response from the initial call. This is also the first use of the uiThread SynchronizationContext to update text in the XAML.

void CompleteOnSend(IAsyncResult result)
{
  IDuplexSessionChannel channel =
    (IDuplexSessionChannel)result.AsyncState;
  channel.EndSend(result);
  _uiThread.Post(UpdateScore, "Registered!" + Environment.NewLine);
}

void UpdateScore(object text)

{
  Scores.Text += (string)text;
}

void PollingLoop(IDuplexSessionChannel channel)
{
  IAsyncResult result =
    channel.BeginReceive(new AsyncCallback(OnReceiveComplete),
    channel);
  if (result.CompletedSynchronously)
    CompleteReceive(result);
}

The PollingLoop method assigns CompleteReceive (see listing 14.17) as the method to handle messages received from the duplex service and then closes the channel when the game is over.

C#:

void CompleteReceive(IAsyncResult result)
{
  IDuplexSessionChannel channel =
    (IDuplexSessionChannel)result.AsyncState;
  try
  {
    Message receivedMessage = channel.EndReceive(result);
    if (receivedMessage == null)
    {
      _uiThread.Post(UpdateScore, "Channel Closed");
    }
    else
    {
      string text = receivedMessage.GetBody<string>();
      _uiThread.Post(UpdateScore, "Score Received: " +
        text + Environment.NewLine);

      if (text == "Game Over")
      {
        IAsyncResult resultFactory =
            channel.BeginClose(new AsyncCallback(OnCloseChannelComplete),
            channel);
        if (resultFactory.CompletedSynchronously)
        {
          CompleteCloseChannel(result);
        }
      }
      else
      {
        PollingLoop(channel);
      }
    }
  }
  catch (CommunicationObjectFaultedException)
  {

   _uiThread.Post(UpdateScore, "Channel Timed Out");
 }
}

void CompleteCloseChannel(IAsyncResult result)
{
  IDuplexSessionChannel channel =
    (IDuplexSessionChannel)result.AsyncState;
  channel.EndClose(result);
}

Creating and consuming a duplex-enabled WCF service take more effort than a standard SOAP service, but there are definitely benefits. The ability to open a channel to the server to get requests as they're available is powerful. Another approach you can take to accomplish this uses sockets, which we'll discuss next.

Sockets require a clientaccesspolicy.xml file with a few changes. The resource element isn't used and is replaced with the socket-resource element. Both element types may exist in the file and apply the style to the specific type or request. The following is an example of a simple client access policy giving access to sockets using TCP over port 4502:

<?xml version="1.0" encoding="utf-8"?>
<access-policy>
  <cross-domain-access>
    <policy>
      <allow-from>
        <domain uri="*"/>
      </allow-from>
      <grant-to>
        <socket-resource port="4502" protocol="tcp"/>
      </grant-to>
    </policy>
  </cross-domain-access>
</access-policy>

Your Silverlight application will typically be served up from port 80, a web server. Sockets, on the other hand, don't require a web server to be present and are on ports other than 80. For those reasons, you must serve up a sockets policy file, because every call is considered cross-domain (or at least cross-port).

You have two options for serving up the policy file. You may either host it on a web server on port 80 on the same IP address as the sockets server, or on a sockets server on port 943. Typically, you'll set up a separate thread or a separate socket server that listens for a connection on 943, sends the socket policy file, and closes the connection.

Before we move on to opening the connection, refer to this book's page on Manning. com for the source code for a simple sockets server.

Opening a socket connection with a socket server can be done in a few simple steps that are similar to the other forms of communicating you've already seen. The first step is to open the socket. Listing 14.18 shows how to open the socket on the client.

C#:
public void OpenTheSocket()
{
  DnsEndPoint tcpEndpoint =
    new DnsEndPoint(Application.Current.Host.Source.DnsSafeHost, 4502);
  Socket tcpSocket = new Socket(AddressFamily.InterNetwork,
    SocketType.Stream, ProtocolType.Tcp);
  SocketAsyncEventArgs socketArgs = new SocketAsyncEventArgs();
  socketArgs.UserToken = tcpSocket;
  socketArgs.RemoteEndPoint = tcpEndpoint;
  socketArgs.Completed +=
    new EventHandler<SocketAsyncEventArgs>(socketArgs_Completed);
  tcpSocket.ConnectAsync(socketArgs);
}

The example creates an endpoint and a socket and then using them to asynchronously request a connection to the remote socket server. You use Application.Current. Host.Source.DnsSafeHost to get the IP address of the host of the Silverlight application in a form usable for creating a socket endpoint. Using this technique to create the endpoint is only useful when the socket and the Silverlight application are hosted in the same location.

Sockets are bidirectional in nature. After you've requested the connection, you need to handle the response. Listing 14.19 shows how to handle the incoming response on the client.

C#:
public void socketArgs_Completed(object sender,
  SocketAsyncEventArgs receivedArgs)
{
  switch (receivedArgs.LastOperation)
  {
    case SocketAsyncOperation.Connect:
      if (receivedArgs.SocketError == SocketError.Success)

     {
       byte[] response = new byte[1024];
       receivedArgs.SetBuffer(response, 0, response.Length);
       Socket socket = (Socket)receivedArgs.UserToken;
       socket.ReceiveAsync(receivedArgs);
     }
     else
       throw new SocketException((int)receivedArgs.SocketError);
     break;

     case SocketAsyncOperation.Receive:
       ReceiveMessageOverSocket(receivedArgs);
       break;
  }
}

You can determine the type of response by evaluating the value of the LastOperation property of SocketAsyncEventArgs, as shown in table 14.2.

Now you need to set up the connection to receive data, as shown here:

public void ReceiveMessageOverSocket(SocketAsyncEventArgs receivedArgs)
{
  string message = Encoding.UTF8.GetString(receivedArgs.Buffer,
    receivedArgs.Offset, receivedArgs.BytesTransferred);
  UIThread.Post(UpdateUIControls, message);
  Socket socket = (Socket)receivedArgs.UserToken;
  socket.ReceiveAsync(receivedArgs);
}

When the message comes in, it needs to be converted into the correct format (a string, in this case); it can then be deserialized using any of the methods described in previous sections, depending on the format of the incoming data.

In additional to the traditional point-to-point connection offered by the Socket class, Silverlight supports multicast sockets where there may be many broadcasting servers or a single broadcasting server, sending to multiple clients.

The Any Source Multicast (ASM) approach enables a single client to receive traffic from any source in a single multicast group. An example of this might be a virtual meeting with multiple broadcasters or an event with several cameras and commentary, all set up as individual servers in the same group.

When Silverlight first attempts to join a multicast group, it sends out an announcement message in the form of a UDP packet to port 9430. In the any-source model, this goes to the group, and any responder in the group can send the ok back to port 9430.

Listing 14.20 shows the basics of connecting to a multicast group in preparation for receiving data.

C#:
private void OpenMulticastConnection()
{
  IPAddress groupAddress = IPAddress.Parse("224.156.5.5");
  int localPort = 1212;

  var client = new UdpAnySourceMulticastClient(
                                 groupAddress, localPort);

  client.BeginJoinGroup(OnBeginJoinGroup, client);

}

private void OnBeginJoinGroup(IAsyncResult asyncResult)
{
  UdpAnySourceMulticastClient client =
    (UdpAnySourceMulticastClient)asyncResult.AsyncState;

  client.EndJoinGroup(asyncResult);

  ...
}

In addition to the any-source approach, you can also designate that you want to listen only to a single server using the Source Specific Multicast (SSM) model.

The SSM approach is more common than the any-source model. Of course, at the time of this writing, neither is particularly common. The source-specific model has been used for broadcasting video and even software images on large campuses and in some organizations. The benefit is the massive savings in bandwidth as compared to more traditional means.

When Silverlight first attempts to join a multicast group, it sends out an announcement message in the form of a UDP packet to port 9430; but unlike the any-source model, this packet goes directly to the single source IP.

Opening the connection and joining the multicast group is similar to the anysource approach, but the constructor takes in the IP address of the single source in addition to the group information.

Listing 14.21 shows how to connect to a multicast group and target a single source address as the address to be listened to.

C#:
private void OpenMulticastConnection()
{
  IPAddress sourceAddress = IPAddress.Parse("192.168.1.1");
  IPAddress groupAddress = IPAddress.Parse("224.156.5.5");
  int localPort = 1212;

  var client = new UdpSingleSourceMulticastClient(
                   sourceAddress, groupAddress, localPort);

  client.BeginJoinGroup(OnBeginJoinGroup, client);
}

private void OnBeginJoinGroup(IAsyncResult asyncResult)
{
  UdpAnySourceMulticastClient client =
    (UdpAnySourceMulticastClient)asyncResult.AsyncState;

  client.EndJoinGroup(asyncResult);

  ...
}

The differences between listing 14.20 and 14.21 are minimal, coming down to the inclusion of the additional IP address in the constructor.

Multicast is just starting to take off in the media, education, and large business sectors. If you're looking at streaming media to a large number of clients, streaming stockticker quotes, or building your own webcasting software, you'll definitely want to learn more about multicast socket development. Fortunately, Silverlight will be able to support you as a good client in those scenarios.

Sockets in general are a great choice when you want to have complete control over the messaging, such as you might when creating a game and you want to have the tightest possible real-time messaging protocol. WCF duplex is a good choice when you're willing to trade wire-level control for the ability to use all the great features, such as automatic serialization, that WCF provides. Different problems call for different solutions, sometimes within the same physical application. It's great to see Silverlight offer such a spectrum of capabilities you can use when connecting applications to the outside world.

Sockets and WCF duplex are great for bidirectional communication between a Silverlight client and a server, or via two machines using the server as a proxy. Straight SOAP and REST are useful when consuming public or application-specific APIs. Silverlight has another mechanism, similar to sockets, that you can use to connect two Silverlight applications running on the same client machine.