Pick a Silverlight RIA scenario
or choose a Web Services style
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) :
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 :
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.