A Cup of Silverlight, RIA & Interoperability : Architecture

PDC2008 : Silverlight on its way to address Business Apps

Steve SFARTZ — Wed, 05 Nov 2008 01:11:00 GMT

Last week at PDC 2008, Jamie Cool demonstrated some very cool work under progress at Microsoft, to deliver a first class development experience for people looking forward to build Business Applications on top of Silverlight.

If you started working on business apps, you miss several capabilities with the current version of Silverlight : see yellow boxes below. This slides comes from Jamie Cool talk available on channel 9.

The availability of Jamie's framework has not been disclosed. If you cannot wait for those bits, have a look at CSLA.Net for Silverlight and here also. CSLA is already available. I did not have the opportunity to play with it yet.

A DPE Team from Switzerland wrote this synthesis of Jamie’s talk :

What this framework will give you are:

- “Shared Business Entities” between tiers that enable client side change tracking (using DiffGrams). Enabling optimistic locking multi records CRUD operations. Validation is also given thanks that the “Entities” can have attributes like [Range(0,100)] for end to end across tiers validation. You can also have a server side method for validation that gets triggered on update for example. All this can run on top of LINQ to SQL, the Entity Framework or even your custom DAL.

- A DataSource control is also provided and it can manage round trip to the server for efficient data paging, filtering and sorting. Basically it uses the IQuerable interface to filter, apply skip/take and order by on the server and the data round trip .

- Wrapper around the Authentication & Membership provider of ASP.NET are also provided. Including SL controls that enable you, with 2 line of code, to add Login functionality directly in Silverlight. It is also populating the Principal object in SL with the authenticated User, making it easier to use the identity in your UI tier. Last but not least you can decorate your server side “Entity” with permissions attributes to enable role base security on top of your “Entity” and CRUD operations.

- Page Navigation model including browser history integration. This make very easy to write multi forms application in SL. It plugs-in to the browser history, enabling user to navigate through the forms with the forward and backwards buttons, without reloading the SL application. It also enable the user to copy and paste around a Url, that will bring the user right back to the right form.

- Additional controls like form control to make even more productive data driven app development will be also provided.

Architecture Series – Pure and Mixed configurations

Steve SFARTZ — Thu, 16 Oct 2008 01:23:57 GMT

This is the first article in an Architecture Series dealing with technical options taken for the Eclipse Tools for Silverlight. Future articles will focus on the XAML rendering architecture, the Eclipse extension points as well as the “MSBuild” project structure preservation option that was taken to allow the back and forth loop.

In the very first words of the eclipse4SL installation, you are told to choose between two configurations : Pure or Mixed Eclipse. Why that ? To minimize the size of the bits to download but also to adapt to your interoperability scenario (any co-workers using Microsoft Tools ?). So what ? That’s enough information to you. Fine, have fun with the Tutorials and please give your feedback. Now let’s talk about the Silverlight 2 runtimes, SDK and Tools for Visual Studio, and how they fit one with another.

If you’re new to Silverlight, you’ll want to begin with the Get Started section of the Silverlight site. After that take an hour or two to go through Scott Guthrie’s tutorials. Finally give a try to Tim Heuer’s technically amazing posts. BTW, have you read the Silverlight 2 announcements from Scott and Tim.

OK let’s start. From the Silverlight Tools page, you’ll notice that Silverlight 2 is composed of a runtime but also a set of development tools (developer runtime, SDK and Visual Studio Tools). Note that eclipse4SL has been added to the list of tools :-).

eclipse4SL uses several pieces of the Silverlight Tools to perform the compilation of your XAML code (you don’t know about XAML, experience it from the HelloWorld tutorial) : MSBuild version 3.5, complementary compilation tasks which come with the SDK and the Silverlight runtime to actually render the bits on the surface as well as run your application.

In a pure Microsoft environment, you would get the following configuration :

If you chose to install a Pure Eclipse configuration, the Silverlight runtime plus the Silverlight SDK are sufficient (the latter has a dependency on MSBuild 3.5 which comes with .Net 3.5). Note that .Net 3.5 SP1 is optional here. Bonus : as eclipse4SL M1 does not support debugging, you may use a standard Silverlight runtime instead of the developer runtime.

Finally, in a Mixed Eclipse configuration, you’ll go back and forth between Eclipse, Visual Studio and Expression Blend but this comes with a maximum of products to install.

Any comments, please use the forums.

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.

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.

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.