What are those SOAP/RPC and XML/REST styles ?

In the Silverlight world, the sole protocol you need to care about is the HTTP protocol. Yet, you can take 2 directions to send and retreive messages from a Silverlight Rich Client application.

The SOAP/RPC style leverages the SOAP specifications and the Remote Procedure Call paradigm (ie, a request message is composed of an operation + arguments, and the response corresponds to a structure of data. Both request and response are formatted in XML in a SOAP enveloppe which enriches the communcation).

On the client side, the SOAP/RPC style is implemented by a subset of the .Net Windows Communication Foundation framework. The basicHttpBinding is the unique supported binding in Silverlight 2 beta 2, and several restrictions apply : SOAP 1.1 only, no WS-Adressing, no WS-* specification. Why those restrictions ? because we want to keep the Silverlight runtime as light as possible (a standard .Net full WCF runtime is about 11 Mo !).

On the server side, you're free to use any SOAP framework and technology as this is a promise of the Services paradigm ... as long as you conform to the restrictions brought by the Silverlight client (see above), otherwise, your Silverlight client will never get a chance to consume your data.

For the scope of the implementations detailled on this blog, we chose server side frameworks that we thought were dominant in their respective community, even if we do not have precise measure about it. Moreover, we wanted free frameworks to allow anybody to replay the samples.

• Windows : the WCF framework which comes with .Net 3.5. The 3.5 version gives us nice SOAP and REST capabilities + the Stream support which enables us to service client access policy file directly from WCF (no HTTP server needed).
• Java : the JAX-WS Reference Implementation from Sun that comes with Java version 6. We have worked a year ago about the compatibility issues between WCF and JAX-WS, thus we feel rather comfortable with it. JAX-WS may be hosted in any Application Server. Again, we choose a free and popular one : Tomcat, from the Apache foundation which Microsoft came to sponsor during the course of our experimentations (welcome Apache, bring us great support and performance for the Windows platform)

By XML/REST style, we mean the retrieval of an XML formatted message in the REST philosophy, where the operation paradigm is replaced by a resource paradigm so that retrieving data maps to a resource invocation through the couple (HTTP ORDER + URI). For example, "HTTP GET /clients/name" or "HTTP POST /clients [XML data coresponding to a new client] . The format of the response can be of any kind, it is declared in the "Content-Type" HTTP header. For the scope of this blog which is RIA oriented, we'll stick to XML as we are focusing on fetching and updating Data (we could have also used JSON but XML is a preferred way for Rich Internet Applications because if its schema / typing capability).

On the client side, the XML/REST style requires the capability to invoke HTTP commands, and getting the results in Async mode to ensure the User Interface remains responsive (ie, UI does not get stuck by network or service latencies. For your information the SOAP/RPC style is also implemented on the client side with an Async pattern, behind the scene).

If you are a Restafarian, you are wondering how much of your REST programing skills you can leverage with Silverlight ? Well, Silverlight 2 Beta 2 restricts to the GET and POST commands of the HTTP protocol. Moreover, you can not control the set of HTTP headers you can transmit to your RESTful service : the sole HTTP header you can modify in beta 2 is the Content-Type.

From an implementation point of view, Silverlight 2 beta 2 provides two programmatic interfaces : WebClient and HttpWebRequest. Which one should you use ? The SL2beta2 breaking changes brings the answer.

"The updated WebClient API provides a much fuller featured WebClient. This changes the guidance around which networking APIs to use:

• • • • WebClient: Use this class when you want an easy to use, event-based API.

      • HttpWebRequest: Use this class when you want a delegate based model and/or the ability to progressively read the response stream. "

To learn more about pratical issues with XML/REST style invocations, read "Limitations when accessing REST services from Silverlight" by Ronny.

On the server side, all we need is a REST style compliant framework. The Windows and Java communities provide us with several options :

• Microsoft delivers WCF and "Astoria, aka ADO.NET Data Services". The latter proposes a great support for Silverlight 2 but that is out of the scope of this blog... therefore, we turned to WCF REST capabilities which come with .Net 3.5.
• Among the Java REST initiative, we had a look at the SUN versus opensouce alternative. It turned out that the Reslet framework developped by Jerome Louvel provides a great REST experience with a unique French flavor. Special thanks to Aurelien Pelletier for making us aware of this technology.

Comments

• Anonymous
  July 29, 2008
  We discussed before what Silverlight is about from a technical standpoint . Moving from theory to implementation,

• Anonymous
  July 29, 2008
  As explained in What are those SOAP/RPC and XML/REST styles ? , the REST support in Silverlight has several

• Anonymous
  July 29, 2008
  As explained in What are those SOAP/RPC and XML/REST styles ? , the REST support in Silverlight has several

• Anonymous
  July 30, 2008
  As explained in What are those SOAP/RPC and XML/REST styles ? , the REST support in Silverlight has several