Silverlight Web Services Team : tools

Some known issues in SL3 Beta

SLWSTeam — Mon, 06 Apr 2009 08:21:00 GMT

We've run across some issues with our web services features in the Silverlight 3 Beta and I want to share these here to hopefully save folks some time and frustration.

Issue: On Windows 7 Beta, you might encounter the following error when generating a proxy: "The element 'httpTransport' cannot contain child element 'extendedProtectionPolicy' because the parent element's content model is empty".

Workaround: On Windows 7, when you use the Silverlight-enabled WCF Service item template, an <extendedProtectionPolicy /> element may be generated in Web.config. This element is not supported by Silverlight. Simply remove the element from Web.config and try regenerating the Silverlight proxy.

Issue: If you use the Silverlight-enabled WCF Service template and you try generating a Silverlight proxy using Add Service Reference on a machine with both Silverlight 2 and Silverlight 3 Beta SDKs, you may get warnings at proxy generation time and errors at runtime. The warnings can include a variety of "Cusom tool" warnings which state that the endpoints found are "not compatible with Silverlight 2" or "No endpoints compatible with Silverlight 2 were found."

Workaround: If you are using Add Service Reference to generate proxies, side-by-side installation of the Silverlight 2 and Silverlight 3 Beta SDKs is not supported. Please uninstall the Silverlight 2 SDK to use Silverlight 3 features. After uninstalling, ensure that the assembly Microsoft.Silverlight.ServiceReference is not present in the machine GAC.

Issue: When using Add Service Reference to generate a proxy to a WCF duplex service (a service built with the System.ServiceModel.PollingDuplex.dll assembly provided in the Silverlight SDK), the generated proxy may not compile and may complain about a missing assembly reference.

Workaround: The proxy for the duplex service is generated correctly, however Add Service Reference will sometimes forget to reference th System.ServiceModel.PollingDuplex.dll assembly in the Silverlight client. Simply add a reference to the assembly (right-click in the Silverlight project, select Add Reference, find the assembly in the list on the .Net tab), and the proxy should now compile.

Hope this is helpful!
-Yavor Georgiev

Some new features for REST services

SLWSTeam — Fri, 13 Mar 2009 20:04:00 GMT

Just a quick announcement here of a release that will be interesting to SL developers who want to access REST services. The WCF REST Starter Kit Preview 2 is now out, go grab it at http://msdn.com/wcf/rest. The release gives you a polished install/uninstall experience, so don't be afraid to try it on your box, it won't muck it up like "preview" software so frequently does.

This release gives you one interesting client-side feature that you may have heard me or Eugene speak about: Paste XML as Types. It's a VS menu item which helps you use XmlSerializer with REST services. Frequently these services use human-readable documentation to describe the XML shape, and it is difficult to hand-code a type to use with XmlSerializer, especially when the XML instance is complex. For example check out this sample XML response from the Yahoo BOSS API. With this new feature it takes one click to generate the type:

Another interesting feature in the release is HttpClient - a sort of specialized WebClient - which can be used to programmatically access REST services using an extensible model for sending HTTP requests and processing HTTP responses. The model enables you to complete common HTTP/REST development activities required to consume an existing service in a fraction of the time you normally spend. Some convenient time-savers include query string support (build URIs as name/value pairs) and serialization support (easily plug in types generated with Paste XML as Types to read the response).

Unfortunately in this release the starter kit only contains a .Net version of HttpClient, which will not compile in Silverlight. We are considering porting this prototype to Silverilght, and if you get a chance to try it on .Net, please let us know of any feedback you have.

Stay tuned for some exciting content coming out over the next week!

Cheers,
-Yavor

New Web Services Features in Silverlight 2 RTW

SLWSTeam — Mon, 20 Oct 2008 16:39:00 GMT

Here is an overview of the new features added since Beta 2.

SOAP Headers

SOAP headers were a big customer request, so we have added headers support in this release. There are two methods to use headers, depending on the customer scenario.

The easier method is useful when you need to get/set a header while invoking a single operation on the service. You can use the OperationContext class, and specifically the IncomingMessageHeaders or OutgoingMessageHeaders property to receive or send a header. Below is a code example where the client sends the header <MyClientHeader xmlns="http://silverlight.net">...</MyClientHeader> to the service.


public Page()
{

     InitializeComponent();
     // Instantiate generated proxy
     Service1Client proxy = new Service1Client();

     // Hook up an event handler when operation completes
     proxy.DoWorkCompleted += new EventHandler<DoWorkCompletedEventArgs>(proxy_DoWorkCompleted);
     using (OperationContextScope ocs = new OperationContextScope(proxy.InnerChannel))
     {

     // We can add "MyClientHeader" SOAP header to the outgoing message. It is important that this comes before calling the operation.
     OperationContext.Current.OutgoingMessageHeaders.Add(MessageHeader.CreateHeader("MyClientHeader", "http://silverlight.net", "..."));

     // Call an operation on the service
     proxy.DoWorkAsync("foo");

     }
}

Now assume we want to get at a header that the service sent back. In this example, the service sent the <MyServiceHeader xmlns="http://silverlight.net">...</MyServiceHeader> header to the client. Note: The old Begin*/End* async pattern needs to be used with OperationContext if you are retrieving the headers sent in a service reply. The event-based async pattern (using *Completed event and *Async method) is currently not supported. Also, please be sure to use exact order of calls demonstrated below.


public Page()
{

     InitializeComponent();
     // Instantiate generated proxy
     Service1Client proxy = new Service1Client();

     // Call an operation on the service using Begin/End async pattern
     ((Service1)proxy).BeginDoWork("foo", doWorkCallback, proxy);

}
// Receive callback when the service responds
void doWorkCallback(IAsyncResult result)
{
     Service1 proxy = (Service1)result.AsyncState;

     using (OperationContextScope ocs = new OperationContextScope(((Service1Client)proxy).InnerChannel)) 
     {

          // Get the service response. This needs to happen before we access the headers.
          string response = proxy.EndDoWork(result);

          // Now we can access the headers of the incoming message. In this case we assume the header "MyServiceHeader" was sent by the service.
          string headerContents = OperationContext.Current.IncomingMessageHeaders.GetHeader<string>("MyServiceHeader", "http://silverlight.net");

          // Do something with response and header

} }

The harder method can be used when you want to get/set headers upon invoking any operation on the service. In that case you would have to use OperationContext every time you call a service operation, which is very clunky. Instead, what would be useful is functionality similar to that provided by WCF message inspectors and the IClientMessageInspector class. Using a client message inspector you can get access to the Message instance just received from or about to be sent to the service, and manipulate the headers directly on the instance. IClientMessageInspector is not part of SL 2, but this code sample demonstrates how to accomplish the same functionality. In the sample, we add a header to every message sent to the service, and the header contains the IP address of the client which is calling the service.

SOAP Faults

Eugene posted about faults just a couple of weeks back. Faults are another major request but unfortunately they are not supported out of the box in SL 2. However, using the same client message inspectors approach and some extra configuration on the WCF service side, rudimentary faults can be enabled. The same code sample linked above demonstrates how to do this. I will put together a more detailed post about the sample in the coming weeks.

Reusing existing types in "Add Service Reference"

If you use "Add Service Reference" to add a reference to the service in your client, it will by default generate a duplicate of any type used by your service operation. Frequently when developing a WCF service and a Silverlight client, you want to declare your types in only one place. Alternatively, maybe your data contract types contain internal logic that you would like to preserve and that logic is lost when "Add Service Reference" generates the duplicate types in the client.

To prevent duplicate types from being generated in the client, you would normally declare the data contract types in a new project, which is referenced by both your WCF service and the Silverlight client. Then when adding a reference to the service, you would select the correct option in the "Add Service Reference" dialog. This way "Add Service Reference" would find the types already referenced in the shared project, and not generate duplicates.

Note: In Silverlight the shared project that contains the data contract types has to be a "Silverlight Library", which can be referenced by both Silverlight projects and regular desktop framework projects. If the shared project is of any other type, you will not be able to reference it from within a "Silverlight Application" project.

This option was already there in the Silverlight version of "Add Service Reference", but it did not work up until this release.

Duplex Services

We have made improvements to the duplex channel shipped in Beta 2:

Client and server side duplex components are now ready for production use, with improved stability, security, etc. In Beta 2 the server-side duplex component was under an "evaluation" license.
Server-side duplex component may now be hosted in Partial Trust
Default timeouts and timeout behavior is “smarter” – no changes should be required for common scenarios

In addition, Eugene has developed a great sample on top of the raw duplex channel model, to simplify duplex usage. On the client side you can use the DuplexReceiver class:


public class DuplexReceiver
{
     // Opens a channel to the service to receive messages using the default PollingDuplexBinding
     public DuplexReceiver(Uri address, IEnumerable<Type> possibleTypes);

     // Opens a channel to the service to receive messages using the default PollingDuplexBinding
     public DuplexReceiver(EndpointAddress address, IEnumerable<Type> possibleTypes);

     // Sends a message to a Duplex service. (The first time a message is sent, connection will be established to the service).
     public void SendMessageAsync(object message);

     // Event that will be called after a message has been sent
     public event EventHandler<AsyncCompletedEventArgs> SendMessageCompleted;

     // Event that will be called for each received message
     public event EventHandler<ReceivedMessageEventArgs> MessageReceived;

     // Disconnects from a Duplex service (can later reconnect again). To permanently close, first call DisconnectAsync and then call Close
     public void DisconnectAsync();

     // Closes the Duplex connection
     public void Close();

     // Other methods and properties omitted for brevity...

}

Instead of using the channel model directly, you can use the SendMessageAsync method to send messages to the service. The MessageReceived event is fired when the service sends the client a message. Note that the DuplexReceiver contructor takes the list of types that can possibly be sent. The sample also provides a server-side DuplexService object, which keeps track of connected clients and can relay messages to the correct recipient, or broadcast messages to all clients.

Support for ChannelFactory<T>

This is an advanced use case: say you want to use a service without generating a proxy to it. Perhaps you are connecting to a complex service and you manually copied over/shared all the contracts and types that the service uses (for example in order to preserve the internal logic of these types). But you never used the "Add Service Reference" wizard so you don't have a proxy class to the service. In this case ChannelFactory<T> can be used to communicate with a service which implements the service contract <T>, as shown below.


public Page()
{
     InitializeComponent();

     ChannelFactory<Service1Channel> factory = new ChannelFactory<Service1Channel>(
          new BasicHttpBinding(),
          new EndpointAddress("http://localhost:49507/Service1.svc"));

     Service1Channel channel = factory.CreateChannel();

     channel.BeginDoWork(new AsyncCallback(doWorkCallback), channel);
}

void doWorkCallback(IAsyncResult result)
{
     Service1Channel channel = (Service1Channel)result.AsyncState;
     string response = channel.EndDoWork(result);

     // Do something with response
}

Note that using this approach, the event-based async pattern is not supported.

Other

Types generated from ADO.NET Entity Data Models (.edmx files) in WCF services intended for Silverlight consumption are now supported. Just use the type generated from a .edmx model as an argument in a service operation.
Internal types and internal members may now be serialized by the DataContractSerializer and the DataContractJsonSerializer (on a per-assembly opt-in basis)
JSON/XML Mapping is now supported (through System.Runtime.Serialization.Json.dll in the SDK), by using the JsonReaderWriterFactory class.
JAXB-style object references in XML are now supported by DataContractSerializer

Have fun using our new feature set!

Yavor Georgiev
Program Manager, Connected Framework Team

Detailed Overview of Silverlight 2 Beta 2 Web Service Features

SLWSTeam — Tue, 10 Jun 2008 11:21:00 GMT

As you have probably read already (in Scott or Tim's posts), Silverlight 2 Beta 2 provides a set of new and improved web service features. This post will go over our Beta 2 scenarions in more detail, and we intend to follow up over the next couple of weeks and drill down into particualr features.

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(http://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.

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

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

Please keep an eye on this blog for more specifics in the next couple of weeks.

Cheers,
-Yavor Georgiev
Program Manager, Connected Framework Team