Transformation of Client/Server application to Windows Azure

Overview

The economics of IT is changing rapidly, and organizations are searching to widen and secure availability of their systems and at the same time lower costs. The cloud concept was introduced to allow an IT consumption model where there is always as much computing power as needed when needed ('on-demand') and without having to invest in connectivity, servers, database access, storage space, CPU power and other infrastructure needs, just as we consume electricity.

Running your systems on Microsoft’s Windows Azure cloud for example would improve and secure the availability, accessibility and scalability (both up and down) of your systems and support the new IT economics.

The challenges

However, in order to take advantage of the cloud's promise of lower cost of ownership, the applications must be built or adjusted to work on that platform.  Even existing web applications cannot always be transferred to Azure without some changes, but for client/server, the task is much more challenging even to the point where it seems impossible.

When coming to transform client/server applications to the cloud and even more so when we want to enable secured web or mobile accessibility, we face some substantial challenges due to the gaps between our source desktop technology and platform and those of our target's. For that reason, even with the best and most advanced tools the bridging process is a challenge.

Most of the known methodologies are actually involve rewrite of desktop systems for the cloud. There are only 2 automatic tools vendor offering on the market and even those still involve some manual intervention. Having said that both vendors are targeting over 95% automation of the process, and the methodologies are unrivalled in terms of productivity and cost effectiveness. Visual WebGui (VWG) is one of those solutions. VWG takes a unique approach. It creates a virtualization layer atop web server, it moves the transformed or generated .Net code to that layer, and then using a patent pending protocol it renders a user interface within a plain browser. The end result is pure .NET code that is a base code for a pure rich web application.

The challenges that VWG solution, called Instant CloudMove had to cope with are among others as follows:

1. Technology & Architecture Differences:
   Multi-threading activities (Running on a multi-user web-server), Thread safety, Large data-sets, Registry I/O, Multiple apps per WebRoles, Dynamic Scalability, 3rd party controls, Custom controls, Printing, Local devices.
2. Maintenance and extensions (The day after  code transposition):
   Web 2.0 UI modernization, Controls extensions, Additional UI and development, Development skills, Azure specific

The transposition process starts with assessment:

Process objectives
The Assessment process provides an estimation of the amount of work that the transposition project to Windows Azure Cloud would require (a readiness test) by listing the automatic portion against the portion of the code that would require manual adjustments due to the gaps mentioned above.

The readiness assessment process
Given assemblies from complied applications, we drill down all types and their members, collecting all typical, relational and usage related data.

For instance, if a type has a method which calls a type which calls a type which opens a dialog, then this data would be collected.

This data is then serialized into a database that contains the whole application mappings.

This step is followed by a detailed analysis of each application scenario. The result of this analysis is a report that contains specific resolution of each and every application scenario, starting with automated migration and up to a possible mapping or even new implementation more suitable for the new platform. And so, our database contains all data of each and every type, including the gaps each type would reveal when migrated.

Following that step we run a statistic algorithm which helps us to segment the expected migration process to the following segments:

• Automatic Migration
• Manual Work – High complexity
• Manual Work – Medium complexity
• Manual Work – Low complexity
• Manual Work – Very Low complexity
• Manual Work – Trivial complexity
• Manual Work – Unknown complexity

The report
Report summary section: This provides an overview of the total automation level as part of the entire application code as well as a segmentation of the manual work to complexity levels. The summary also provides a bottom-line readiness level score between 1 and 10.

Saving indicators section: Basing on statistic algorithms, you can see the summary report translated into resource saving indications compared to the rewrite alternative. These indications represent the segments from the report summary.

 
Report Data Section: In this section you can see a drill down into the gaps found listed by types. Each issue is described and accompanied by a proposed solution.

 
The Azure deployment prediction calculator
The Visual WebGui AssessmentTool includes a calculator specifically designed to measure the resource consumption of the application when deployed and running on the Microsoft Windows Azure Platform.

The calculator takes into account parameters which are related to the management of the application and to the common usage scenarios as well.

Example:
By average, my application handles 500 concurrent users who work 20 days a month for 8 hours a day. My application is almost entirely independent from other software services.
My application maximal database size is 10GB.

The common usage scenario involves the average user opening about 4 screens/forms that present 10KB of data and making about 5 logical operations per screen. The average user performs the common usage scenario 15 times a day.

The average user performs 12 registry transactions and uploads 10 files of 120KB per day.

 
This report includes various cloud resources such as Azure instances, Storage, databases, bus connection etc. which can be used to indicate the cost of running the application on Windows Azure.

Visual WebGui is natively integrated in Microsoft stack

Platform:
Visual WebGui is basically an ASP.NET extension. Any Technological aspect is basically the same and any challenge on that arena would be met when considering Visual WebGui as ASP.NET.

Handling data:
Visual WebGui’s approach is to handle all logic and data on the server and to only virtualize the data on the screen. In that sense, it is different from most web deployments around. This means that no data related issues would be major ones. Actually, any data related challenges would probably be related more to the transferring and rendering of large amounts of data. In this case the solution would be in the infrastructure that Visual WebGui provides such as paging.

Runtime:
When using Visual WebGui, you get the entire client behavior without needing to create any. HTML rendering, client event handling etc. are included in the Visual WebGui infrastructure. Any challenge that involves client behavior that is not recommended / possible on the web, would be met either by mapping to other existent API or by extending the current application behavior. In any case, Visual WebGui code is open and absolutely customizable and extendible.

Once a decision is taken the transposition process starts

Process objectives
When entering the transposition process we expect any as little changes to our code as possible. Transposing projects to Visual WebGui should provide us with single layer code – C# / VB.NET.
In the case of 3rd party components, any component which can be used on the new platform should remain unchanged. Otherwise it should be resolved successfully.

TranspositionTool
Running the Visual WebGui Transposition Tool requires the actual source code in a complied state.

For each of the referenced Assemblies, the user has the option either to keep the reference the old assembly or to generate a new project to replace it.

For instance, if I use a library which handles complex calculations, than I can use it with Visual WebGui as well.

But if I use a 3rd party components which do not fit the web, then the reference to their assembly would be transformed to a reference to a new proxy project assembly generated with the entire public API already in store.

 
The transposition process begins like the assessment process - given the source code from complied applications, we drill down all types and their members, collecting all typical, relational and usage related data.

For instance, if a type has a method which calls a type which calls a type which opens a dialog, then this data would be collected.

This data is then serialized into a database that contains the whole application mappings.

Then the actual new code is rendered.

The transposed code would be in the source language. The application project is rendered in its own – basically as is. Any referenced type which does not exist in the defined referenced assemblies will be referenced via a newly generated project designated specifically for that purpose.

Any referenced 3rd party type which was defined as a part of a closed assembly will be rendered via a newly generated project designated specifically to replace that assembly.

The Migration challenges and how they’re met:

Customization and modernization opportunities

Web 2.0
Visual WebGui offers a set of controls and behaviors designated for web/cloud which can be used in order to advance the application UI to Web 2.0 and HTML5.

Form based development
Visual WebGui allows customizing and maintaining the transformed application using the same powerful and simple Form based tools in Visual Studio. It uses .NET concepts and methodologies such as WYSIWYG, point and click, drag and drop. All client behavior - Event handling, styling is as transparent as you want them to be.
 
Customizability
In the process of upgrading to Windows Azure Visual WebGui also allows the opportunity to easily customize the UI Look & Feel using the Visual WebGui Theme Designer. This is done by simply overriding properties, images and other client resources which can be totally assigned to the graphic designers as it requires no programming what so ever.

Images overridden in the Visual WebGui theme designer

Summary

As a part of its vision, Visual WebGui takes on the challenge of migrating client/server applications to the web, cloud and mobile. The unique Visual WebGui approach and concepts allows the shortest path from client/server applications to Windows Azure cloud due to the fact that a minimal amount of manual adjustments is required and even that can be done in single layer language under .NET framework.
With Visual WebGui, you can have the best of all worlds: Strong stable servers on which the entire application is run, Rich internet application UI fully customizable and extendible, full application session state, and for cloud migration – great saving on CPU, bandwidth and other cloud resources.

In this white paper we have overviewed the assessment process using the Visual WebGui AssessmentTool. We have discussed the assessment report and have seen how to deduce our application’s readiness for migration.

This paper also discussed the challenges foreseen beforehand and how they are met and we have also overviewed the transposition process using the Visual WebGui TranspositionTool. Lastly, we have overviewed the possibilities opened for us once we have transformed our application using Visual WebGui CloudMove tools.

A video demonstrating the solution is available here.