A Cup of Silverlight, RIA & Interoperability : XML/REST

Eclipse4SL : M2 released + REST and SOAP Guidance

Steve SFARTZ — Mon, 12 Jan 2009 00:24:00 GMT

The Eclipse Tools for Silverlight enter year 2009 after achieving its 2008 commitments !

First of all, SOYATEC did a great job at correcting more than 30 bugs (and 200 unit tests to ensure first quality) but also at enhancing the plug-in to provide a better support for Silverlight (improvement of the XAML editor, support for Styles and Embedded Custom Components in XAML preview…).

To get the full list of features, see this detailed blog entry: Release 1.0.0 M2 is ready. Moreover, when you install the plug-in, you are now given the options to also install the source code and/or documentation.

Second, guidance is now provided to connect Silverlight applications to Java business logic. Because REST and SOAP make sense, we chose to provide guidance for both. We also chose to use opensource frameworks and tools, such as the Tomcat server runtime :

REST guidance : the Restlet framework from Noelios Technologies was chosen to illustrate the Silverlight to Java calls in REST style,
SOAP guidance : JAX-WS implementation from Apache (CXF) was chosen to illustrate the Silverlight to Java calls in SOAP style.

Start building Silverlight RIA in eclipse today !

With Eclipse4SL M2 plus the guidance to connect Java business logic, you can now build Silverlight applications in what we call the Pure Eclipse configuration or you may complement your design by using Expression Blend, and collaborate with .Net teams using Visual Studio.

If the XAML experience is now completed, it is fair to say that the C# development experience is still rudimentary (no code assist and no debug). Therefore, in real world, you’ll still need Visual Studio for the Silverlight C# code development and debug tasks (Hopefully, Visual Studio Web Express is free).

Improving the C# experience as well as supporting other dev platforms is still on the Eclipse4SL roadmap… stay tuned…

If you want to support this project, feel free to vote on EPIC, but also contact the Eclipse4Sl Team if you want to appear among the SLDT proposal interested parties.

How-To : Silverlight accessing Java REST services (Part 2 – No Cross Domain : Tomcat/Eclipse)

Steve SFARTZ — Wed, 06 Aug 2008 11:43:00 GMT

The HowTo serie demoes Silverlight accessing Web Services in various configuration. In this post, we will demonstrate a REST service consumed by a Silverlight client application where the Site of Origin hosts the Web Services. This scenario is categorized as a D2D scenario without cross-domain policy.

The XAP package, the REST service Eclipse project and the Silverlight Eclipse project are available as an attachment to this post.

Technical Environment

REST services are built with the Restlet framework and hosted in Tomcat
The Silverlight application is also hosted in Tomcat

Because the Site Of Origin and the Web Services reside in the same host, no Cross Domain policy is required.

To successfully install the technical environment, please take the following step :

Build the scenario detailled in HowTo : Silverlight accessing Java REST services (Part 1 - Cross Domain : IIS + Tomcat)

If you don’t feel like doing the previous step, the XAP package available as an attachment contains a Silverlight client which is configured to access a REST service at http://localhost:8080/Restlet-servletfirstResource/items.

The REST service is also available as an attachment to this post allows to do a GET and POST method to get a list of items or to insert a new one.

Download the attachment and unzip it. There are two needed parts : the Silverlight XAP package and the Restlet Eclipse project.

Host the REST service with Tomcat

Import the Reslet-servletfirstResource project into your Eclipse workspace :

go to File –> Import
Then chose General—>Existing Projects into Workspace
Select the root directory, Browse to the Restlet-servletfirstResource folder, then click on Finish. The Restlet-servletfirstResource has now been imported into your workspace

Run the project on Tomcat Server. check that http://localhost:8080/Restlet-servletfirstResource/items is accessible you should get the following result :

Host the Silverlight application in an Eclipse project running on Tomcat

Create a new Dynamic Web Project

Press Ctrl+n to go to the New Wizard Project, under Web select Dynamic Web Project.
Call it REST-SilverlightClient and ensure that the Target Runtime is set to Apache Tomcat 6.0
If Eclipse prompts you to switch to J2EE perspective, accept it.

In the REST-SilverlightClient project, create the WebContent\ClientBin folder and copy the XAP package into it.
Now we need to host it through an Active X control :

Right click on WebContent folder and select New—>JSP, call it index
Edit index.jsp, in the Head part put the following script that catches Silverlight Error.

 <script type="text/javascript">

     function onSilverlightError(sender, args) {

         var appSource = "";

         if (sender != null && sender != 0) {

             appSource = sender.getHost().Source;

         var errorType = args.ErrorType;

         var iErrorCode = args.ErrorCode;

         var errMsg = "Unhandled Error in Silverlight 2 Application " +  appSource + "\n" ;

         errMsg += "Code: "+ iErrorCode + "    \n";

         errMsg += "Category: " + errorType + "       \n";

         errMsg += "Message: " + args.ErrorMessage + "     \n";

         if (errorType == "ParserError")

             errMsg += "File: " + args.xamlFile + "     \n";

             errMsg += "Line: " + args.lineNumber + "     \n";

             errMsg += "Position: " + args.charPosition + "     \n";

         else if (errorType == "RuntimeError")

             if (args.lineNumber != 0)

                 errMsg += "Line: " + args.lineNumber + "     \n";

                 errMsg += "Position: " +  args.charPosition + "     \n";

             errMsg += "MethodName: " + args.methodName + "     \n";

         throw new Error(errMsg);

 </script>

In the Body part, instantiate a Silverlight control by adding the following HTML code, ensure that the param named “source” has is value set to the XAP package URI relative to index.jsp Web Page:

<div id="silverlightControlHost">

    <object data="data:application/x-silverlight,"

            type="application/x-silverlight-2-b2"

            width="100%" height="100%">

        <param     name="source" value="ClientBin/REST-JavaServiceItem.xap"/>

        <param     name="onerror" value="onSilverlightError" />

        <param     name="background" value="white" />

        <a     href="http://go.microsoft.com/fwlink/?LinkID=115261"

            style="text-decoration: none;">

               <img src="http://go.microsoft.com/fwlink/?LinkId=108181"

                 alt="Get Microsoft Silverlight"

                 style="border-style: none"/>

        </a>

    </object>

    <iframe style='visibility:hidden;height:0;width:0;border:0px'></iframe>

</div>

Run the project on Tomcat Server and the Silverlight control will appear in the Eclipse Web Browser :

The great thing about that is that you will be able to test your REST Service and the Silverlight application without running multiple Development Environments.

- Ronny Kwon

B2C scenario : Customer Environement

Steve SFARTZ — Thu, 31 Jul 2008 17:50:00 GMT

The B2C scenario corresponds to Web applications accessed by customers, traditionnaly built with some dynamic HTML/AJAX technology running on the server side, that have been elected to leverage the Silverlight capabilities (enriched user experience, vector based contents, scaling, rich media…).To comply with the scope of this blog, we’ll concentrate on RIA scenarios, where the customer accesses private data from a Silverlight Client.

As listed in Silverlight scenarios for Rich Internet Applications, the following constraints apply to the Customer Environment scenario :

Infrastructure security is mandatory : it includes a DMZ to protect the Web Server and access to the Web Services and optional SSL/HTTPS communications depending on the confidentiality of the data accessed.
Protocol adaptation is required if the application is interfaced with pre-existing Web Services that cannot be immediatly consumed by Silverlight. This extract work is performed by a mediation layer, materialized in the schema below by the Services Gateway. Moreover, the Services Gateway in the Customer scenario can enforce the alignement of the incoming messages with the entreprise governance policies.
Authentication & authorization is required for Line of Business Applications to secure read and write access to Entreprise Data. Form based authentication would be the preferred way in this scenario. If you need Claim based authentication, take a look at the B2B scenario.
A cross domain security file is required to access the Services Gateway

We plan to document this scenario by extending the “B2E with mediation” scenario, with Form Based Authentication & Authorization constraints. If you have technical requirements not list here, there’s good chance the B2C scenario can be enriched from the B2B scenario.

B2B scenario : Partner Environment

Steve SFARTZ — Thu, 31 Jul 2008 13:10:00 GMT

The B2B scenario corresponds to Enterprise Web Services exposed to a partner through a Rich Client application, traditionnaly built with some dynamic HTML/AJAX technology running on the server side, that have been elected to leverage the Silverlight capabilities (enriched user experience, vector based contents, scaling, rich media…).

As listed in Silverlight scenarios for Rich Internet Applications, the following constraints apply to the Partner Environment scenario :

Infrastructure security is mandatory : it includes a DMZ to protect the Web Server and access to the Web Services and SSL/HTTPS communications to protect the confidential data owned by your enterprise and shared with your partner.
Protocol adaptation is required if the application is interfaced with pre-existing Web Services that cannot be immediatly consumed by Silverlight. This extract work is performed by a mediation layer, materialized in the schema below by the Services Gateway. Moreover, the Services Gateway in the Customer scenario can enforce the alignement of the incoming messages with the entreprise governance policies.
Authentication & authorization is required to secure read and write access to Entreprise Data. Claim based authentication would be the preferred way in this scenario. If you want wish to use Form based authentication, have a look at the B2C scenario.
A cross domain security file is required to access the Services Gateway if not host on the Site of Origin.

We plan to document this scenario by extending the “B2E with mediation” scenario with a Services Gateway (such as Managed Services Engine) and SSL/HTTPS.

B2E scenario : Intranet Environment

Steve SFARTZ — Thu, 31 Jul 2008 12:10:00 GMT

The B2E scenario corresponds to internal Web applications, traditionnaly built with some dynamic HTML/AJAX technology running on the server side, that have been elected to leverage the Silverlight capabilities (enriched user experience, vector based contents, scaling, rich media…).

As listed in Silverlight scenarios for Rich Internet Applications, the following constraints apply to the Intranet Environment scenario :

Infrastructure security is optional as we are in a IT governed environment,
Protocol adaptation is required if the application is interfaced with pre-existing Web Services that cannot be immediatly consumed by Silverlight. This extract work is performed by a mediation layer, materialized in the schema below by the Services Gateway .
Authentication & authorization is required for Line of Business Applications to secure read and write access to Entreprise Data. Windows integrated authentication would be the preferred way for an intranet scenario. If you want wish to use Form or Claim based authentication, take a look at the B2B and B2C scenarios.
A cross domain security file is needed if the Services Gateway is implemented or if the Site Of Origin does not host the Web Services (as in interoperability scenarios where the Site of Origin and the Web Services rely on two different technologies).

We plan to experiment SOAP/RPC and XML/REST configuration in Full Windows, Full Java and Mixt environment.

We’ll also demonstrate how Web Services invoked from Silverlight can leverage the Authentication & Authentication facilities provided by IIS/ASP.NET through interoperabiliy.

How-To : Silverlight accessing Java REST services (Part 1 - Cross Domain : IIS + Tomcat)

Steve SFARTZ — Wed, 30 Jul 2008 15:42:00 GMT

The HowTo serie demoes Silverlight accessing Web Services in various configurations. In this post, we will demonstrate a REST service consumed by HTTP GET and POST requests issued from a Silverlight client application. This scenario can be categorized as a D2D scenario with a cross domain policy.

The Silverlight example described below is available as an attachment to this post.

Technical environment

REST services are built with Restlet and hosted in Tomcat
The Silverlight application is hosted under the Visual Studio embedded Web Server code name "Catalina" (which delivers a subset of the IIS capabilities)

Because the Site of Origin and the Web Services reside in different hosts, a Cross Domain policy is required at the Services host’s root (/clientaccesspolicy.xml">http://<serviceshostname:port>/clientaccesspolicy.xml)

Implementation of the REST service

To get an overview of the Restlet framework, complete the tutorials : First Steps and First Resource.

Service development with Restlet can be summarized as follow :

The Application class is the entry point to the Restlet service. It binds a URI to a specific Resource.
The Resource class describes how the service behaves on a specific URI invokation.

After completing the tutorials above, deploy the firstResource service as a Servlet hosted by Tomcat.

Invoke the Restlet service with the URI http://localhost:8080/Restlet-servletfirstResource/items. Assuming that Tomcat is running on port 8080 and that your Restlet project name is Restlet-servletfirstResource, you get the following response :

  <?xml version="1.0" encoding="UTF-8" standalone="no" ?>

  <items>

     <item>

        <name>item1</name>

        <description>description of item1</description>

     </item>

   </items>

Enabling Cross Domain Access

Since the REST service and the Silverlight application are hosted in different hosts, we need to overpass the Cross Domain Issue. Create at the root of the REST service host, a clientaccesspolicy.xml file with the following content :

<?xml version="1.0" encoding="UTF-8"?>

<access-policy>

    <cross-domain-access>

        <policy>

            <allow-from http-request-headers="*">

                <domain uri="*"/>

            </allow-from>

            <grant-to>

                <resource include-subpaths="true" path="/"/>

            </grant-to>

        </policy>

    </cross-domain-access>

</access-policy>

Consuming a REST service with Silverlight (GET method)

We chose the WebClient API to request the REST service, and LINQ to process the XML response. XmlReader is another parsing option, and Serialization (Xml or DataContract) is another one.

Invocation of the REST service

First of all, in your UserControl, declare a MyItem class that will map the XML response elements.

   1:  public class MyItem

   2:  {

   3:      public string myName { get; set; }

   4:      public string myDescription { get; set; }

   5:  }

   1:  // List of Items

   2:  IEnumerable<MyItem> Items = null;

Now, let's send a HTTP GET method request to /items URI so we can retrieve every items

   1:  private void getAction()

   2:  {

   3:      WebClient webclient = new WebClient();

   4:      webclient.DownloadStringCompleted +=

   5:        new DownloadStringCompletedEventHandler(client_DownloadStringCompleted);

   6:      webclient.DownloadStringAsync(new Uri("http://localhost:8080/Restlet-servletfirstResource/items"));

   7:  }

Processing the XML results

Let’s process the results using LINQ support for XML :

   1:  void client_DownloadStringCompleted(object sender, DownloadStringCompletedEventArgs e)

   2:  {

   3:      if (e.Error == null)

   4:      {

   5:          XDocument xmlItems = XDocument.Parse(e.Result);

   6:          // use LINQ to XML to parse the response

   7:          Items = from child in xmlItems.Element("items").Descendants().ToList()

   8:                  // restrict the selection to item children

   9:                  where child.Name.LocalName=="item"

  10:                  select new MyItem

  11:                      {

  12:                          myName = (string)child.Element("name"),

  13:                          myDescription = (string) child.Element("description")

  14:                      };

  15:      }

  16:  }

Sending Data to a REST service with Silverlight (POST method)

Use the WebClient to send a HTTP POST request to the /items URI, by adding two parameters : name = "Foo" and description = "Bar" :

   1:  private void postWebClient()

   2:  {

   3:      WebClient webclient = new WebClient();

   4:      webclient.UploadStringAsync(

   7:        new Uri("http://localhost:8080/Restlet-servletfirstResource/items"),

   8:        "name=Foo&description=Bar"

   9:      );

  10:  }

Warning : Notice that if you try to hit the same URI several time with the HTTP GET method, the results do not get refreshed but remain the same. Further explanations about this caching issue are available here.

- Ronny Kwon

Limitations when accessing REST services from Silverlight

Steve SFARTZ — Wed, 30 Jul 2008 12:35:00 GMT

As explained in What are those SOAP/RPC and XML/REST styles ?, the REST support in Silverlight has several limitations :

Only the "Content-Type" HTTP header can be accessed from the Silverlight client code.
The WebClient works fine in most scenarios, yet turn to HttpWebRequest if you need to control the response flow.
HTTP methods are limited to POST and GET (no PUT, nor DELETE support) - see below
You may encounter Browser Caching issues - see below

1. Manipulating a REST service model is done via 4 basic HTTP methods: GET, POST, PUT, DELETE . The last two methods are not yet supported by Silverlight :

2. Cache issue

You request data from a REST service by invoking a URI with the WebClient class. As all service communications are async in Silverlight, you process the result through an handler.

   1:  WebClient client = new WebClient();

   2:  client.DownloadStringCompleted +=

   3:  new DownloadStringCompletedEventHandler(client_DownloadStringCompleted);

   4:  client.DownloadStringAsync(new Uri(“http://foo.org/service/items”));

You may experience that the same data gets always retrieved, even when modified on the service side. To solve this problem :

either set the Cache Control with "no-cache" value on the service side,
or ensure that subsequent calls are made with differents URI (so that the results do not get cached). This is mandatory if the REST framework on the service side does not support cache header customization, as it is the case for the Restlet framework (as of July 2008, Jerome Louvel is working on it).

client.DownloadStringAsync(new Uri(“http://foo.org/service/items?cache=" + DateTime.Now));

- Ronny Kwon

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

Steve SFARTZ — Wed, 30 Jul 2008 10:57:00 GMT

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.

D2D scenario : Developer Environment

Steve SFARTZ — Mon, 28 Jul 2008 17:17:00 GMT

This scenario is typically used in development phase when you are building a Silverlight rich client that connects to new business Logic. It is mandatory that the business logic is new to ensure you have enough control to enforce a configuration where the Site Of Origin and the Services Host reside on the same node. If you face a configuration where you need to interface with Business Logic exposed by existing Web Services from a distinct node or requiring protocol adaptation, turn to the B2E scenario.

As listed in Silverlight scenarios for Rich Internet Applications, the following constraints apply to the Developer Environment scenario :

No infrastructure security constraints since this is a dev/test env (No HTTPS, no DMZ)
No protocol adaptation is necessary as we develop brand new services here (ie, messages format & exchange protocol correspond to the Silverlight client capabilities, they can be directly consumed)
Authentication & authorization may need to be handled if required at production/deployment time : this point is covered in the B2E scenario.
A cross domain security file is needed if the Site Of Origin does not host the Web Services, as in interoperability scenarios where the Site of Origin and the Web Services rely on two different technologies.

We plan to experiment the following configurations :

SOAP/ RPC style (operation oriented)
1. Mixed configuration : IIS for Site of Origin + Tomcat and JAVA-WS for Web Services
  - with a cross-domain policy
  - or by servicing Web services request from IIS through the Tomcat connector for IIS
2. Full Java configuration : Tomcat for Site of Origin + JAVA-WS for Web Services
3. Full Windows configuration : IIS for Site or Origin + WCF services (SOAP style) for Web Services
  - with a cross-domain policy
  - or with the IIS built-in integration of WCF services through SVC resources
XML/ REST style (resource oriented)
1. Mixed configuration : IIS for Site of Origin + Tomcat and the Restlet framework for Web Services
  - with a cross-domain policy
  - or by servicing Web services request from IIS through the Tomcat connector for IIS
2. Full Java configuration : Tomcat for Site of Origin + Restlet for Web Services
3. Full Windows configuration : IIS for Site of Origin + WCF services (REST style) for Web Services

Silverlight scenarios for Rich Internet Applications

Steve SFARTZ — Mon, 28 Jul 2008 15:56:00 GMT

From the architecture described in the previous post a cup of Silverlight, a drop of Architecture, you may experience several technical requirements :

Infrastructure Security
- DMZ (if the application is internet facing),
- Secured transport (HTTPS) if private communication has to be enforced (Mandatory in B2B and B2C environments)
Application Security
- Authentication may be Form, Windows or Claim based depending on the consumer (employees, subcontractors, partners or customers)
- Authorization may be role based from various repositories (Active Directory, Claims, SQL Database)
Application Topology
- The consumed Web Services are likely to be hosted on a distinct node in case of re-use or interop scenario.
- In new project development scenario, the Site of Origin may also host the Web Services.
Services Gateway and Protocols Adaptation
- The consumed Web Services may not be directly accessible due to security topology (ie, requires some kind of Gateway, Reverse Proxy)
- In case of Web Services re-use, they are likely to be exposed through protocols and/or formats incompatible with the Silverlight WCF client capabilities (ie, requires some kind of Mediation, Adaptation)

To comply with these Real World variants, we propose to categorize Silverlight Rich Client Applications into scenarios that you 'll may mix to conform to your requirements.

D2D (Developer To Developer) - Development Env

B2E (Business To Employee) - Silverlight App on an Intranet, eventually consuming pre-existing Web Services

B2B (Business to Business) - Silverlight App delivered to partners, consuming pre-existing Web Services with federated security enforcement

B2C (Business to Consumer) - Silverlight App delivered to customers, eventually consuming pre-existing Web Services with form based security enforcement

In future posts, we discuss the architecture and an implementation sample with interoperability in mind.

A cup of Silverlight, a drop of Architecture

Steve SFARTZ — Mon, 28 Jul 2008 13:04:00 GMT

We discussed before what Silverlight is about from a technical standpoint. Moving from theory to implementation, let's discuss today the architectural challenges when building a Silverlight App. The following considerations apply to Siliverlight 2 beta 2 (current version of Silverlight as of July 2008) :

A SilverLight app runs locally in the browser which renders a Web page composed of HTML code and a XAP archive. This archive contains presentation code (XAML), logic code (JavaScript, .Net or Dynamic) and Resources (Images… that may be accessed for Silverlight logic code).
The Silverlight app may interact with Services in two ways and through 5 different API’s
- HTTP stack
  - HTTP GET, POST / REST style : WebClient, HttpWebRequest
  - SOAP over HTTP : WCF client
- IP Socket
  - TCP : System.Net TCP Listener
  - Socket : System.Net Sockets
  - Duplex Channel: As a bonus, Silverlight 2 beta 2 brings among its set of news features, a duplex channel communication through its WCF support.

As we focus on Silverlight interop in this blog, we will detail the HTTP aspects only. Here is some global consideration from what we've learned so far :

To fully understand the above, may we bring some complementary vocabulary and explanations :

SOO - Site Of Origin designates the Web Site from which the XAP is downloaded, ie, your HTTP Web Server
The Business Logic is composed of the Web Services exposed to your SL client.

The Web Services may be running on the Site Of Origin or not. Depending on this topology, your security settings need to be adapted by adding a cross domain access policy at the root of the Web Services host endpoint. This secures the invocation of services from a Silverlight client whose Site of Origin does not host the requested services endpoint. For more information about cross domain, read scorbs post "Silverlight HTTP Networking Stack - Part 2 (Cross Domain Communication Overview)"

As the Web brings two services styles (SOAP/RPC & XML/REST), Silverlight supports both. To decide which one to use for your Silverlight data interactions, read "What are those SOAP/RPC and XML/REST styles ? ".

From those considerations, we propose to decline the Silverlight Architecte described above into Real World Enterprise Scenarios focusing on D2D, B2E, B2B or B2C scenarios: Silverlight scenarios for Rich Internet Applications,

To finish with, let's discuss interoperability. We named our Web & App Server layer as Interaction & Transactional Services to refer to Microsoft SOA Reference Architecture Model where 2 nature of SOA are introduced : SOA to interact and SOA to transact, the two being connected through interop channels. This is where our Silverlight plus ... Java, .Net, PHP, Ruby... comes into play.