Migrating traditional web applications to Silverlight

The move from ASP.net to Silverlight is primarily driven by two factors – leverage the powerful user interface authoring features supported by Silverlight and the client side computing capabilities that it offers. Most companies have significant inventory of traditional HTML based applications. There is always a need in such companies to rapidly leverage the rich user experience of Silverlight while not having to undertake a potentially huge rewrite effort.

WHAT LIES BENEATH A SILVERLIGHT APPLICATION
Silverlight or WPF everywhere is a plug in that is delivered through a browser. It is built on the current, updated graphical subsystem from Microsoft – Windows Presentation Foundation (WPF) and integrates multimedia, graphics, animations and interactivity into a single run time environment. A Silverlight application is compiled into a self sustained package that is delivered by a host web application to a client. This execution model allows Silverlight packages to deliver the power of desktop computing over a browser. This also allows capability to build connected applications that are a step up from asp.net and Ajax applications.

The runtime allows the host application to interact with this package. HTML Bridge is a technology in Silverlight that enables you to access the HTML Document Object Model (DOM) from managed code, and to call managed code from JavaScript. This feature, called HTML Bridge, allows the Silverlight package to interact with the host web application.

CHOOSING AN IDEAL MIGRATION SOLUTION
Migration of an asp.net application to Silverlight is not necessarily a line by line code conversion. It involves revamping the user experience to unleash the power of Silverlight and also re architecting the application to leverage the client computing capabilities. There should be an analysis and assessment phase followed up by development and testing.

There are also key business objectives that need to be met while selecting an optimal migration solution. The most prominent being
• Time to market
• Integration with existing applications in the enterprise
• Seamless user experience
• Turnaround time for changes

An assessment of the existing applications in the enterprise is of key importance, as it needs to be fully understood from a functional and technical perspective, to provide a complete migration strategy.

Based on the results of the assessment there are three ways to port a web application to Silverlight:

--> POWER CONTROLS: SILVERLIGHT CONTROLS HOSTED IN SINGLE ASP.NET PAGE
Here specific controls are ported to Silverlight and hosted within the asp.net web page. The application will continue to remain asp.net while specific functionalities alone are ported to Silverlight.
Key examples are Stock tickers, weather widgets etc.

--> SEPARATE APPLICATIONS WITH TOUCH POINTS
In this type of integration Silverlight and asp.net applications both exist in parallel and with limited interactivity. The two applications will have navigational touch points. The user moves from one application to the other based on his selection.

--> HYBRID: ASP.NET PAGES HOSTED WITHIN A SILVERLIGHT HOSTING ENVIRONMENT
If the destination technology is Silverlight, this is the recommended alternative to a total rewrite. In this approach, we build a hosting environment that is capable of delivering asp.net and Silverlight pages. The asp.net application is iteratively migrated to Silverlight.

For most corporates with significant inventory in traditional HTML web applications option 3 - building a hybrid hosting environment is the best option. This allows for the shortest time to market delivering the maximum impact to the user. The singular hosting environment ensures that the user experience is seamless and not that of a mash up of two disparate applications and technologies.

The hybrid hosting environment delivers the following key benefits:
 The application will be immediately Silverlight – maximize end user experience by leveraging powerful features like animations, vector graphics, advanced typography, 3D drawing, adaptive documents etc.
 Multi-content hosting – migrate only the necessary content to Silverlight.
 Migrate iteratively – identify and migrate few pages at a time. Evolution, not revolution is the mantra.
 Backward compatibility – Allow content to remain in the preferred technology. Reports and other ‘preferably HTML’ content can continue to exist in HTML form.

EVOLVING AN APPLICATION TO SILVERLIGHT
EVOLUTION VS REVOLUTION
Revolution is a jump to the next generation technology in one big undertaking. Cut over takes place quickly and on a large scale: the entire entity is transformed. Evolution is to take incremental steps to the next generation over a longer period. It reduces risk and upheaval. And it allows for assessment of options and planning accordingly. Evolution tends to deliver superior performance over the long-term. Evolution means stepping from the current to the next generation. The steps are incremental, over a period of time.




Building a hybrid hosting environment also allows for backward compatibility with predecessor products and processes. This allows the entities to exist in preferred form and technology while being a singular unit. This allows revolutionary goals to be achieved through an evolutionary process.

MIGRATION METHODOLOGY
Based on the technical and business drivers at play, we suggest the following migration methodology to the desired destination solution.


At a high level the migration methodology needs to involve the following steps




Fig: iterative development methodology

--> Assessment

a. User experience finalization
b. Identifying the migration candidates

In this phase a thorough assessment of the existing applications is done. A validation of the architecture based on the assessment is done.

The primary tasks completed will be user experience finalization and identifying the migration candidates. The outputs of this task are wire frames or mockups, and guidelines for the user experience.

Also as part of the identifying the migration candidates a list of items to be eventually migrated is identified. Also a priority on which the migration has to be performed is identified. Using these two artifacts a high level iterative migration plan is drawn up. An outline of the destination product, with the details of its constituent applications is also drawn up.

--> Infrastructure development
a. Develop Hosting framework
i. Build host shell and utilities
ii. Develop integration enablers and utilities
In this phase the infrastructure to enable the iterative migration is developed. First based on the output from the previous Assessment phase, a detailed design is drawn out for these components, followed by development. Here the following deliverables are built
1. A hosting framework
2. Utilities and enablers for integration
3. Common services
--> Service Orientation
This task can happen in parallel with the Infrastructure development. All the data access and business logic that needs to be accessed by both Silverlight and asp.net application is exposed as services. This includes
1. Legacy services(COM+ etc)
2. Common business logic
3. Data access methods
--> Iterative Development
a. Source Code Development
b. Changes to framework
In this phase the actual migration happens. Here based on the priority drawn up in Assessment phase, a set of items are taken up for migration. Detailed design is performed and development is done. If the set of tasks needs an update to the framework, that too is done here.
--> Deployment
a. Testing and stabilization
b. Production deployment

The application is tested and stabilized and deployed to production. 
 

Building Highly Testable Web Applications With ASP.Net MVC

Web applications are notorious when it comes to testability. The problem is further compounded when applications have a complex user interface. Recently we did an architecture consulting for one of our clients in the financial industry for a web based application which is part of their core product offering. The product is an enterprise solution which supports multiple client configurations. The application is built on classic ASP and COM relying on the main database of the product for storage apart from a centralized file storage system.
One of the key challenges faced by the application was testability. With code and markup being tightly coupled, what some ASP.Net developers derisively call as spaghetti code, it was close to impossible to write functional unit test cases for the application. The most likely solution was migration of the application to ASP.Net with clear separation of code from markup. However past experience told us that this works well only if the pages are fairly simple and complex pages often resulted in bloated code behind files which are hard to test and maintain. This lead us to consider ASP.Net MVC as a suitable solution approach.
In the world of web applications adoption of MVC pattern opens up possibilities like never before. It is common practice to have minimal code in the code behind and move the operation logic in its entirety to controllers with the ability to support multiple views. This enables clear separation of view from the presentation logic and thereby creating opportunities for testing the application which hitherto didn’t exist. Typically a test double is hooked up with the controllers and one could proceed with testing well before the look and feel of the user interface gets finalized.
The folks at Microsoft foresaw this and introduced the ASP.Net MVC framework as an alternative approach to the traditional web forms based development model. ASP.Net MVC paves way for building applications which follow test driven development (TDD). Controllers could be unit tested outside the ASP.Net process itself and any unit testing framework could be leveraged for this purpose.
There are other benefits as well such as ASP.Net MVC comes with a powerful URL routing mechanism. No longer are requests made to specific web pages with an extension. For example, the URL MyServer.com/Orders/Status/1234 would replace MyServer.com/Orders/ Status.aspx?id =1234. Note the difference: ASP.Net MVC URLs follows a more RESTful style compared to the old web forms model.
Few points that need to be kept in mind before making key decisions:
1) ASP.Net MVC ushers in a radical change in the underlying framework. Pages no longer receive requests; instead requests are routed to controller classes which manage the views. It is quite possible to support other higher level frameworks on top of MVC, for instance building a composite user interface with Composite Web application block with an MVC approach is possible.
2) ASP.Net MVC as a framework addresses building user interfaces in a fundamentally different way. However when it comes to strategies for authentication, session management, use of providers, authorization, localization, caching etc there are no changes. An interesting implication is parts of an application rebuilt with ASP.Net MVC can coexist with rest of the application still using the web form post back model making a strong case for migration.
3) ASP.Net MVC introduces more elements in the projects than one would normally have. It is typical for a complex web page to be broken into multiple views and controllers. In a sense, few tightly coupled larger components are broken up into several loosely coupled parts. Sometimes this is viewed as a disadvantage.
4) One does really need to think in terms of MVC to realize the benefits, and better design skills can make a telling difference. ASP.Net MVC applications are typically high on design.

Since the key issues of our client revolved around testability and a maintainable codebase, ASP.Net MVC seemed to be a natural fit. However there were some concerns around ASP.Net MVC being a brand new framework in its beta version (a release candidate is available now). However such fears were unfounded for the following reasons:
1) ASP.Net MVC though it was a beta version came with an explicit go live license from Microsoft. Microsoft had experimented with several preview editions for almost a year, before deciding the bits for the beta edition. A "go live" license ensured backward compatibility in future versions.
2) Building web applications on MVC is an established norm, though it is new to ASP.Net. Frameworks like Ruby on Rails rely heavily on the MVC pattern. Even before ASP.Net MVC , third party solutions were available for building ASP.Net applications using MVC pattern. More notable among them is Monorail framework of Castle project. ASP.Net MVC works well with these third party solutions. For example ASP.Net MVC optionally lets users plug in MonoRail’s view engine.

Apart from suggesting the ASP.Net MVC approach, recommendations were made around strategies for session management, caching, storage, load balancing, use of third party controls & themes. All considerations applicable to ASP.Net applications hold good for applications built on ASP.Net MVC.
As with any new framework one can expect some churn, however the most recent cut of ASP.Net MVC is quite stable and without doubt a whole new way for building great web applications.

MSDE to SQL Express 2008 Migration

One of our Consulting engagements demanded for an MSDE to SQL Express 2008 database upgrade to occur at the time of the client application installation. So we proposed a solution for using SQL Management objects (in short SMO) to accomplish this task. SMO is defined as a collection of objects that are designed for programming all aspects of managing SQL Server. SMO are industry standard practice to provide an abstraction to the end user with the Databases. Here’s our experience with SQL Management Objects on this engagement.


Objectives:-
Our customer happens to be a giant in the retail industry. The customer had a Purchase Order Management Client application which was several releases old built on the .NET Framework 2.0 and SQL Server 2000 Microsoft Data Engine (MSDE). The client application uses a SQL Server 2000 Desktop Database Engine (MSDE) database to store most data, consisting of lookup data synchronized with the central server and worksheet data that are created and modified by the end user. The current security architecture of the application uses a SQL defined account. In order to support the latest release for the client application our development team decided to upgrade from MSDE to SQL Express 2008, since SQL Express 2008 had better security features than MSDE.

Challenges:-
The major challenges that we faced during this engagement was to come up with a strategy so that the end user/Technical support Staff had very minimal amount of task while performing this upgrade. So our strategies included,

1. A silent installation script for installing SQL Express 2008 with a named instance
2. When the application is upgraded, move the old worksheet data from the old MSDE instance to new SQL Express 2008 instance.

Silent Installation of SQL Express 2008
Few pre requisites for SQL Express 2008 installation are,

1. .NET Framework 2.0 SP2 or higher
2. Windows Installer 4.5

Since our new application was being built on .NET 3.5, we had to upgrade all the retailers’ machines with .NET Framework 3.5 SP1, but this does not ensure that we have Windows Installer 4.5 installed on the machine.
So we had to write a custom MS DOS batch script which checks for the Windows Installer 4.5 and proceed further with SQL Express installation.

Database Migration from MSDE to SQL Express 2008
Now comes the interesting part of the whole migration where, we had to come up with a strategy to migrate the existing database from MSDE to SQL Express 2008. To this the SQL Management Objects (or SMO) came in very handy for us to do the development.
Here is flow chart of actions that needs to be taken in order to migrate the database from MSDE to SQL Express 2008,


Here is the code snippet where we do the database migration from MSDE to SQL Express 2008.
First of all we must add the following references for SMO, The Class diagram for the same is as below,
Class Constructor:-
The class constructor is being used to initialize the Server objects and to obtain a handler to the MSDE and SQL Express Instances.

Getting physical file names of the database in MSDE:-
This function gets all the physical files names of the database, a database can include several Data files and log files collections, The FileGroupCollection objects is a collection of all the data files associated with the database, while the LogFileCollection object as the name suggests has a collection of all the log files of the database. It becomes essential for us to obtain all the physical files of the database before migrating it to SQL Express 2008.

Detaching the database from MSDE and attaching it to SQL Express 2008
The Server object gives us methods to detach and attach a database; these methods are used as below:

We hope the information was useful. We will come up with such information more in the future.