Udostępnij za pośrednictwem

Detailed Overview of Silverlight 2 Beta 2 Web Service Features

  • Artykuł

Src: Silverlight Web Services Team

 

Duplex Communication (Server Push)

This has been the most requested feature from our customers since the release of Beta 1, and it enables some useful scenarios like building chat and monitoring apps. Duplex allows the client to expose a set of operations that the server can call to send (push) information to the client. Previously addressing the browser-based client was not possible using the web service stack, so we are very excited to ship this feature in Beta 2.

Duplex support is delivered in two assemblies: one that plugs into your WCF service, and the other one which plugs in to the Silverlight client. Once you install the Beta 2 SDK, you will get the following assemblies:

  • C:\Program Files\Microsoft SDKs\Silverlight\v2.0\Libraries\Server\Evaluation\System.ServiceModel.PollingDuplex.dll
    This is the server-side assembly. For details on it usage and how to build a duplex WCF service, see this topic in the documentation. The assembly provides you with the server-side PollingDuplexBindingElement, which allows you to build a custom binding, You can then build a custom ServiceHost, which uses the custom binding to host your service contract. A service contract hosted this way will support ServiceContractAttribute.CallbackContract, which is how you specify the client operations that the service can call. The topic referenced above goes through all these details and shows you a finished duplex WCF service.
    You may have noticed the "Evaluation" folder name in the path. This assembly is provided on a different license than the rest of the Beta 2 product, and is not meant for production apps. We intend to put some more work into the API and tune the performance before this component is ready for production environments.
  • C:\Program Files\Microsoft SDKs\Silverlight\v2.0\Libraries\Client\System.ServiceModel.PollingDuplex.dll
    This is the client-side duplex assembly. For details on its usage and how to build a Silverilght client for a WCF duplex service, see this topic in the documentation. The assembly provides you with the client-side PollingDuplexHttpBinding, which can be used to create a channel to talk to the WCF duplex service. This is covered by the above topic.

You might remember Eugene's blog post, which talks about a typed "receiver" experience, which also takes care of deserialization. We are working on this and will likely release it as a code sample on silverlight.net in the coming weeks.

LINQ over JSON

Many web services provide APIs which return JSON data instead of POX or SOAP, and we want to make sure Silverlight provides great support for these types of services. So far the only way to interact with JSON in Silverlight has been to deserialize it into a type, which we have defined already to match the structure of the JSON. However this becomes impractical for APIs that return a lot of JSON data. Take Facebook for example: just asking for a user's information returns almost a page of JSON, and it would be impractical for a Silverilght developer to have to construct a type to match this JSON, especially if the Silverlight app is a mashup and interacts with multiple complex JSON APIs. In situations like this, we would prefer to "dot into" the JSON object and treat it as more of a dictionary, as opposed through the deserialization mechanism.

Beta 2 introduces a brand new feature called JsonObject, which is also new to the .Net platform. JsonObject allows you to "parse" a JSON string and then use it as a dictionary in Silverlight, as shown in this documentation topic. Using the following JSON string as an example,

[{"IsMember" : true, "Name" : "John", "Age" : 24}, {"IsMember" : false, "Name" : "Paul", "Age" : 44}, {"IsMember" : true, "Name" : "George", "Age" : 12}]

we can parse it into the JsonObject users, and then access its members this way: users[0]["Name"], users[1]["Age"], etc. We can then construct LINQ expressions such as

var members = from member in users
where member["IsMember"]
select member;

The FoodFinder sample on silverlight.net provides a real usage example of the Yahoo! Local JSON API (download the source code). The following LINQ query is used by the sample to dynamically filter the results returned by the service based on two sliders that the user controls.

var members = from restaurant in (JsonArray)results["ResultSet"]["Result"]
where float.Parse(restaurant["Rating"]["AverageRating"]) >= rating.Value
              where float.Parse(restaurant["Distance"]) < distance.Value
select restaurant;

Configuration Support

In Beta 1, the binding and endpoint address had to be specified in code and passed as parameters to the proxy constructor.

BasicHttpBinding binding = new BasicHttpBinding();
EndpointAddress address = new EndpointAddress(<localhost/service.svc>);
ServiceClient proxy = new ServiceClient(binding, address);

In Beta 2 the "Add Service Reference" feature in Visual Studio will generate a ServiceReference.clientConfig file, which will contain the binding and address configuration informaton, and the proxy can be constructed with its default constructor.

ServiceClient proxy = new ServiceClient();

This allows us to change the binding/address without needing to recompile the Silverlight control. In addition configuration exposes some knobs on the binding, which can be tweaked for security or performance reasons:

<binding name="BasicHttpBinding_IService" closeTimeout="00:59:00" openTimeout="00:53:00"
receiveTimeout="00:15:00" sendTimeout="00:21:00" maxBufferSize="65530"
maxReceivedMessageSize="65531" textEncoding="utf-8" />

This documentation topic explains the different settings available.

Tooling Improvements

We have added the "Silverlight-enalbled WCF Service" Item template. When a WCF service is added using this template, the binding in the service configuration is automatically switched to basicHttpBinding.

Silverlight-enabled WCF Service Item Template

IntelliSense over .clientConfig files is now supported. As you start editing the file you will get useful popups with the supported schema.

IntelliSense over .clientConfig

SOAP Improvements

We have made some general SOAP improvements in Beta 2:

  • Custom SOAP headers and faults in service - ignored and don't generate uncompilable code
  • “Wildcard” schema in service (like xsd:any or xsd:anyattribute) - now works and doesn't generate uncompilable code

And specifically if your service is a WCF (or in some cases .ASMX) service:

  • XML types like XmlElement/XElement/XmlNode[]/XmlAttribute/etc in service - now work and don't generate uncompilable code
  • Types that implement ISerializable in your service (except for collections) - now work and don't generate uncompilable code
  • Stream type in service - now works and doesn't generate uncompilable code
  • MessageHeaderAttribute in Message Contracts - ignored and doesn't generate uncompilable code

Comments