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) :

1. 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).
2. 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.