Rich Internet Application Architecture

Article
04/04/2008

Rich Internet Applications

Rich Internet Applications (RIA’s) combine the maturity, stability and scalability of service orientation with state of the art display technology to create the next wave of web based distributed applications. One of the drivers behind the move to RIA’s is that in an Internet based world, the competition for visitors (eyeballs) and the need for those visitors to come back (stickiness) is central to the success of online business. The role of the designer is, now more than ever, as important to the success of RIA projects as are developers.

As Professor John Heskett states in his paper ‘Why Design Matters’, ‘…designers specialize in the detailed interaction between what a company produces and the lives of its users...’. The designer has the ability to make a connection with the user through layout, color, shape, text and movement. As a result of the success of these design decisions, it is more likely that the user will make an emotional connection to the application and by association, the company. The user will fall in love with the application and desire to use its features over and over again. Eyeballs and stickiness…the goal of RIA’s.

As architects, it is our role to define the process, tools and patterns that will allow designers and developers to work together to deliver Rich Internet Application solutions.

The Microsoft Platform for RIA’s

The Microsoft Platform offers the cross browser, cross platform technology as well as the collaborative work environment and integrated tools set that designers and developers will need to create this type of solution. Microsoft Silverlight is a cross-browser, cross-platform, and cross-device plug-in for delivering the next generation of .NET based media experiences and rich interactive applications for the Web. Expression Blend is the IDE for designers for creating Silverlight and Windows Presentation Foundation (Rich Desktop) solutions. Visual Studio 2008 is the IDE for developers that provides multi-language development, debugging and testing.

A major improvement in the designer/developer workflow is provided by the integration between Expression Blend and Visual Studio. Both Expression Blend and Visual Studio work on the same set of project files and folder structure. A project placed under source code control can be extracted and worked on by either the designer using Blend or the developer using Visual Studio. When updates are checked back, they can then be accessed by other team members without modification to the source or project structure. There is no impedance mismatch between what the designer intends and what the developer delivers into production.

Expression Blend 2.5 March Preview

Visual Studio 2008

Designer/Developer Workflow

The files that designers work on are the files that describe the user interface. With Silverlight, these files are expressed in the eXtensible Application Markup Language (XAML, pronounced zamel). XAML is an XML based .NET language for describing the hierarchical structure of an event driven user interface that is constructed of layout controls, vector graphics, animations and user controls. Expression Blend provides the WYSIWYG graphical IDE for editing and debugging XAML.

Developers work in code, C# or VB, and use Visual Studio to perform editing and debugging. XAML provides the bridge between the world of the designer (layout, color, fonts, animations, vector graphics, etc.) and the world of the developer (object orientation, classes, services, data, etc.).

The XAML and the code are related to one another through the partial class construct in .NET.

XAML

Code Behind

The XAML and code are further integrated by events raised by the objects that make up the UI and the event handlers implemented in the code behind.

XAML

Code Behind

The beauty of the partial class construct is that the object model defined by XAML is fully accessible in the code behind so that any aspect of the user interface can be dynamically modified by code. In addition, XAML snippets, strings of XAML, can be instantiated at runtime and injected into the user interface by using the CreateFromXAML() API.

Silverlight Application Architecture

The architecture of Silverlight applications is not ground breaking. If you have experience in developing AJAX applications, this model will feel very comfortable. Silverlight provides a rich client technology that can go beyond the capabilities of DHTML and Javascript, is easier to implement, test and debug, is more secure and leverages existing Web development infrastructure, development skills, best practices and patterns.

The client application is hosted within the Silverlight browser plug-in. The plug-in provides runtime services and browser DOM integration. The client, once initialized, has the ability to invoke services that provide end-points for accessing data, executing transactions and kicking off workflows. The client can optionally use Isolated Storage to store user specific state.

Application Deployment and Load

Silverlight assets are deployed to a Web Server. The assets that make up a Silverlight application are:

· HTML page that bootstraps the application via the Object tag or an ASP.NET page that bootstraps the application using the asp:Silverlight server side control

· XAP file that is a compressed ZIP that contains the compiled .NET Assemblies along with an XML formatted Application Manifest that lists the NET Assemblies that make up the application

When a page that contains a reference to a Silverlight application is browsed to, a check is made to see if the Silverlight Plug-In is installed. If it is not, a graphical banner is displayed:

When user clicks on the banner it will initiate the download and installation of the Silverlight Plug-In. The Silverlight 2 plug-in is ~4MB in size. The download takes a few seconds on a broadband connection and once downloaded the application runs. There is no need to restart the browser or the system.

Silverlight 2 contains the .NET Common Language Runtime (CLR) and a version of the .NET Framework version 3.5 designed for use within the context of the browser. The CLR cracks the XAP file, parses the manifest and loads the necessary .NET assemblies. The CLR then invokes the entry point of the application and execution begins. The default entry point for the application is found in the App.Xaml.cs and is called Application_Startup()

This function instantiates the Page class which is defined using the .NET partial class construct and is defined in part by XAML and in part by code as we saw above. The constructor of the class typically contains your application initialization code. One common pattern that you may do on startup is to invoke services to access application data in order to initialize the user interface.

Invoking Services

Silverlight provides a complete networking stack so that you can easily integrate the user interface with your services. Services can come in the form of Javascript Object Notation (JSON), RSS, Plain Old XML (POX) and SOAP. Communication can be performed by using the WebClient class or by using a WCF proxy to a Web service. HTTP request/response is supported through WebClient – this is how you do POX, JSON, and RSS. You can generate WCF proxies using the "Add Service Reference" functionality in Visual Studio. Note that data can only be transmitted asynchronously.

Cross Domain Calls

Using Silverlight for cross-domain communication requires guarding against several types of security vulnerability that can be used to exploit Web applications. Cross-site forgery is a class of exploits that becomes a threat when allowing cross-domain calls. This exploit involves a malicious Silverlight control transmitting unauthorized commands to a third-party service, without the user's knowledge. To prevent cross-site request forgery, Silverlight only allows site-of-origin communication by default for all requests other than images and media.

For example, a Silverlight control hosted at https://contoso.com/mycontrol.aspx can only access services on that same domain by default – for example https://contoso.com/service.svc, but not a service at https://fabrikam.com/service.svc. This prevents a malicious Silverlight control hosted on the https://contoso.com domain from calling unauthorized operations on a service hosted on the https://fabrikam.com domain.

To enable a Silverlight control to access a service in another domain, the service must explicitly opt-in to allow cross-domain access. By opting-in, a service states that the operations it exposes can safely be invoked by a Silverlight control, without potentially damaging consequences to the data the service stores.

Silverlight supports two different mechanisms for services to opt-in to cross-domain access:

Place a clientaccesspolicy.xml file at the root of the domain where the service is hosted to configure the service to allow cross-domain-access.
Place a valid crossdomain.xml file at the root of the domain where the service is hosted. The file must mark the entire domain public.

ClientAccessPolicy.xml

CrossDomain.xml

For purposes of this series I have deployed one WCF service with 2 methods and configured it using the above techniques. If you want to experiment with Silverlight 2 Cross Domain support, you can generate a WCF proxy for the SoundsFamiliarService.

Location: https://www.bobfamiliar.com/soundsfamiliarservices/soundsfamiliarservice.svc

Service Contract

· CD[] GetCDList() – return an array of CDs

· Track[] GetTrackList( string CDId ) – return a list of Tracks for a particular CD

Details on the development, deployment and invocation of WCF series is covered in Part 2 of this series.