Web or Cloud - Which Direction Will Client Apps Take?

Introduction

It is a well-known theory that the web and cloud will gradually force out client applications. All that would be needed is a computer with Internet access. In fact, even the full-fledged operating systems in use today would be excessive, as data will be stored on remote servers with necessary software available in the form of various web services. Could this really happen?

Despite all the benefits that may be initially apparent, there are many opponents to this theory. Advocates believe that at some point, the web will completely supplant client applications. The opponents are adamant that the web will never be able to fully replace many client applications, and that some users, and in particularly enterprises with sensitive data, will never agree to store their important and confidential information on remote servers that could potentially be accessed by others.

Rather than re-hash the already-exhausted debate, this article will highlight the key challenges of migrating and web enabling client application to be consumed over the web and cloud, as well as offer possible solutions from the views of developers and architects.

Background

This article is being written on the premise that there are two general types of applications. The first is web apps, which can theoretically jump onto cloud infrastructures fairly easy, although there are three major considerations that should be made before migrating:

  1. Which cloud can host the specific type of web apps? The ability to select the cloud provider and move from one cloud provider to another is very important. A guideline answer to this question would probably be virtual machine-based clouds (i.e. Amazon or VMware v-Cloud infrastructures) which can host most web applications. Shared computing platform, such as Windows Azure or Google App Engine, will progressively support the major infrastructures, but most of the unique back-ends will be left behind, at least for a few years.
  2. What is the cost to deploy to the cloud? Will this be a smart move from an economic perspective? The financial aspect is one of the most important questions today, as the cost-effective calculation is often the deciding factor in business and management strategy. But can we really estimate those costs in advanced?
  3. From a security perspective, can we really expose our organizational apps to the web or the public cloud without severely risking the data security? This is probably the most difficult question to try and answer, as cautious developers will probably say that some apps should never go to the web or cloud because they contain too much data that simply cannot be deployed anywhere else but on-premise. Others will claim that everything has a solution or one is forthcoming shortly, and all apps should be expected to move to the cloud in a secure manner very soon. The truth is probably somewhere in between, however, it will not be wise to ignore this security factor.

The second general type of application is desktop apps. Until recently, moving any organizational desktop app to the web, and even more so to the cloud, actually meant a re-engineering of the entire application to fit the new architecture. Once the technological aspects were complete, then the aforementioned key issues of cost, security and hosting were raised.

With an understanding of the application types, it is important to understand the primary options for migration. Manual re-engineering is an undertaking that involves severe costs and an extensive time frame. Its advantage is that it uses the most advanced coding patterns to transfer the code to a form that leverages the cutting edge technologies and practices. With Code Translation, the amount of work is largely dependent on what is translated (and to what it is being translated); however, inter-architectural translations, such as a desktop single user app to be based on asynchronous web, stateless and multi-user environment, is somewhere between an enormous amount of manual work and an impossible undertaking. Finally, the third migration option is web enablement of existing code. This approach may be the only reasonable solution, as it reflects the need to maintain the current investments in code and is also able to emulate and maintain the same paradigm of development and maintenance along with the same user experience.

For developers, it is very clear that the ultimate solution is having the same desktop code running on the web, being able to maintain it using the same skill-sets, and not having to re-engineer the code in order to maintain its UI and behavior but simply have it running on the web. If that is, indeed, the ideal solution, then what option, practically speaking, do developers have today?

Solutions

The initial solution is client virtualization. Citrix, Remote Desktop, and other similar options would do the job of deploying the same desktop application over the web. The clear advantages are that after the fact, there is no coding at all. Moreover, it can easily be implemented on almost any desktop app. The downside is more serious, such as its high cost (based on a per-user license); it is highly demanding in terms of the hardware required to support large number of users; non-extensible; problematic security model as it opens an independent TCP port and installs a local client; and the high bandwidth consumption, due to the fact that the transportation is based on bitmaps.

There is a second solution that is growing in popularity among developers, who favor its architectural approach, the "Empty Client". This architecture is an emerging open source method, which offers a different approach to architecting, developing and deploying AJAX applications. To better understand it, we will compare it to the classic Thin and Thick (also referred to as Fat or Smart) client approach and to traditional AJAX structures. Empty Client offers a new balance between the Thin and Thick Client approaches and a new channeling of the AJAX calls.

The Thin Client model communicates with a central processing server, which means that there is little hardware and software installed on the user's machine. This allows all end users' systems to be centrally managed with software deployed on a central server location, as opposed to being installed on each individual system. This is usually used in places where it would create a major headache for IT to both deploy and maintain so many user stations. In contrast, a Thick Client will provide users with more features, graphics and choices, thereby expanding the opportunities to make the applications much richer. Unlike Thin Clients, Thick Clients do not rely much on a central processing server because most of the processing is done locally on the user system, and the server is accessed primarily for storage and data retrievals purposes. For that reason, Thick Clients often are not well-suited for public environments. To maintain a Thick Client, IT needs to maintain all systems for software deployment and upgrades, rather than just maintaining the applications on the server. Additionally, Thick Clients often require operating specific plug ins, again posing more work and limitations for deployment. The trade-off is a more robust and local computing environment.

Making technological history, Empty Client is a mutual approach for the web and cloud, offering the best of both worlds - the desktop and web environments (or Thick and Thin Client approaches) and enhancing them with AJAX. With the Empty Client approach, an optimized protocol generates and extends server side power, typically achieved with Thin Client, and make it available for data centric, customizable and scalable web applications, typically achieved with Thick Client. Furthermore, the Empty Client leverages the client's processing power to render the UI and to activate any of the server's instructions. The Empty Client uses asynchronous refreshes, and a JavaScript-based engine to communicate with the server. Instead of communicating at the component level in a scattered way, it communicates the incremental updates, asynchronously through one central pipeline. What this means is that rather than open numerous routes to the server, it channels all communication through its centrally controlled pipeline; Essentially, Empty Client relies on AJAX but does all the plumbing under the hood.

It also achieves the highest scalability and performance that, in the past, were enabled only with the Thick Client approach. Hence the name "Empty Client", because it doesn't run any logic or data manipulation on the client, doesn't expose data or logic, and doesn't require exposing web services consumed by the client, which is a non-secured very common practice on traditional AJAX development methods. Empty Client is sometimes referred to as Clever Client because with this approach the UI control's process is an integral part of the control just like a single layered desktop control only divided into the control rendering part (on the client) and the control's logic part (on the server); it executes on top of traditional and standard web platforms and creates the feeling of a native client side application that usually run as Thick or Fat client only with a Thin client footprint. The Empty Client differs from the Thin client also because it runs on any plain browser with no plug-ins and it does not transfer bitmaps. This way, the Empty Client is really offering the best of both worlds by allowing central computing with the strong processing power that clients typically have today.

How does the Empty Client approach work?

With Empty Client, the application is developed and run on the server, and its user interface is "projected" onto the client. A unique algorithm is charged with the task of transferring user interactions and application responses back to the client. While other frameworks utilize AJAX to enhance scattered parts of the applications (like individual controls), the Empty Client approach seeks AJAX to accomplish one specific need: acting as its main pipeline to the server. This explains why it is so secure, why there is no need to code AJAX, and why there is a very speedy performance regardless of the size or the amount of data that is processed and presented by the application. All one has on the client is a small JavaScript kernel that is responsible for UI drawing on the browser (creating standard HTMLs), receiving the user interaction and sending it back to the server. This interaction passed by the client cannot instruct the server or change the application's behavior since the entire logic is executed and validated exclusively by the server. With this approach, security hazards are completely removed as there is "nothing" on the client to hack into or manipulate to get access into the server.

Empty Client Solutions

One option for Empty Client is the WOW model - Windows Over Web, which is enabled by the Empty Client approach. This will emulate the desktop environment on plain web platforms and enable almost immediate usage of WinForms based apps over the web, VB 6.0 migration to .NET using translation tools (a non-inter-architectures translation) and then run it over the web. This approach also provides the best starting point for any desktop application migration to the web as it emulates the same mature dev paradigms. Its positive attributes include not needing business logic changes; user experience remains the same; Very low migration project costs; no operational costs on top of the standard web or cloud deployment; and maintenance using existing skill-sets

The downside issues are that this is not an after the fact solution and it requires a new .NET project; partially automatic processes are available for WinForms and VB 6.0; however, other desktop technologies can use it as the best starting point; and that it will not improve old coding patterns to new ones; however, maintains the same business logic which can be improved over time.

A Closer Look at Empty Client

WinForms over Web

If you are performing a WinForms migration to ASP.NET, using any AJAX 3rd party controls (for a richer UI experience), you will have to consider:

  • Entirely new API.
  • Entirely new update approach.
  • Entirely new look & feel C"b," or work hard to customize the UI to look the same.
  • Lightening the amount of data transferred to the client and presented at any given time to avoid severe latency.
  • The potential of compromising on features list due to the web limitations.
  • Handling security holes created as a result of opening services consumed by client side AJAX and transferring business logics to the client.

The Windows over Web methodology is integrated into Microsoft Visual Studio and provides the exact same API and set of tools/capabilities which are provided out-of-the-box with WinForms 1.0 and 2.0. This fact enables the native capability of simply copying any existing WinForms source code to a Windows over Web (VWG: Visual WebGui) project and providing a fully functional equivalent web application.

Web or Cloud - Which Direction Will Client Apps Take?

The Process

The 3 basic steps of migration (see figures 1 to 5):

  1. Open a new VWG application.
  2. Copy the code from your WinForms project into this new web application.
  3. Replace any reference to WinForms API namespace ("System.Windows.Forms") within the code to VWG API reference ("Gizmox.WebGUI.Forms").

[figure1.png]

[figure2.png]

[figure3.png]

[figure4.png]

[figure5.png]

Any standard WinForms application which is using the 58 WinForms out-of-the-box controls will then compile and execute as a plain web application.

The outcome of this short process is an ASP.NET based solution in terms of deployment and runtime and has the following properties:

  1. Deployment is copy & paste equivalent to an ASP.NET web site.
  2. Server infrastructure requires an IIS and .NET CLR only.
  3. The application can be consumed from any plain browser - no installation is made on the client.
  4. Minor static and cached footprint on the client ~200kb of plain JS and HTML code due to the Empty Client concept.
  5. Support for multiple presentation layers with the same code base (DHTML/Silverlight or Smart Client)
  6. Maintain a single layer of code, no need to write or maintain JavaScript, HTML and services
  7. Highly secured due to the Empty Client concept.
  8. Considerations & Exceptions

    There are 3 major challenges you might have with the process which you can quantify in advance and estimate the amount of work that has to be done in order to migrate your application:

    1. Minor differences between the VWG API and WinForms which are mainly caused by architecture differences.
    2. The amount of 3rd party controls that are used in your application. This section describes a situation of using some non-WinForms out-of-the-box controls (for example Infragistics or DevExpress controls etc). In those cases you can select the most suitable solution from the following 3 options:
      • Choose a similar control from the WinForms out-of-the-box, adjust your code to use it and then perform the migration process.
      • Select an equivalent 3rd party ASP.NET control (Infragistics, Telerik, DevExpress etc.) which provides the same functionality, wrap it by a click of a button in VWG and adjust your code to use it.
      • Write your own VWG custom control which will perfectly suit your needs and then adjust your code after the migration process to use this control.

    Adjustments of a single user desktop application to a multiuser web environment.

    This section summarizes some of the major issues of transforming a single user application to a multiuser application sharing the same CPU, Memory space and other resources.

    • Thread safety - since a WinForms application can contain static members which are accessible to a single user, you should now consider one of the following:
      • Replacing those static members to a synchronized multi-thread safe data structures.
      • Lock critical read/write sections to protect concurrent multi user access.
      • Remove the statics and find instance or DB based solutions.
    • Memory load - in a desktop application, there might be places when the original consideration of the amount of memory in use was based on the assumption that the executing machine is local. Therefore, many items are loaded to memory simultaneously without limitation.

      Now, on a shared memory environment, when the server does the heavy lifting, the amount of memory consumed by each user will set the number of concurrent users that can be served by each server.

      The following steps are recommended:
      • Consider loading items to memory on demand (keep only the headers and the identifiers in memory).
      • Remove any large objects read to memory, for example, don't save binary objects to memory, instead write the binary to the response stream directly to the client.
      • Prefer DB based paging on entire prefaces and memory based paging. VWG provides mechanisms to enable this easily.

    Summary

    Migration of any WinForms application to the web has the following advantages:

    • In 3 simple steps you will be able to get very close to a working web application.
    • The effort you have to make in order to accomplish a fully functional web application is measurable.
    • The application can keep using the existing BL and DL layers, and only the UI is either migrated automatically or adjusted.

    VB6 over Web

    The Process

    VB 6.0 based desktop applications can be transferred to web in 3 different approaches:

    1. VB 6.0 Project - WinForms .NET Project - VWG .NET Project
      Migrate the VB6 using Artinsoft tools and services to a WinForms desktop application and then follow the process of WinForms applications migration as described in the first section of this document.

      [figure6.png]

    2. VB 6.0 UI using VB 6.0 DL/BL C"b ' VWG UI using VB 6.0 DL/BL
      The application will keep using the existing BL/DL layers as COM/COM+ VB6 based components and only the UI is mimicked within a VWG project using the productive proven tools of WinForms . The VB 6.0 to WinForms wizard of Artinsoft which exists within Visual Studio to make the process partially automatic.

    3. VB 6.0 Project C"b ' VWG Project
      The entire application is mimicked within a VWG project and .NET using the productive proven tools of WinForms. The VB6 to WinForms wizard of Artinsoft which exists within Visual Studio to make the process partially automatic.

    Considerations & Exceptions

    Except for the considerations and exceptions mentioned in the previous section "WinForms based desktop applications", there are two additional subjects derived from the VB history of the project:

    1. The source project written in VB6 and might use non-Thread-Safe win32 or native API resources C"b," those should be handled as potentially dangerous to the multi user web environment.
    2. Threading Model: activating a COM/COM+ components coded in VB6 is using"Single Thread" or "Single Thread Apartment" threading models; Consider using the "STAThread" attribute decoration above any method that is accessing VB6 based COM/COM+.

    Summary

    Migration of VB6 application to the web using has the following advantages:

    • The application can keep using the existing BL/DL services -- no re-write or re-engineering is required.
    • UI concepts, design patterns and practices can be migrated as is.
    • UI elements and API in VB6 are very similar to WinForms so that migration of the UI to Visual WebGui is quite native.
    • The effort you have to make in order to accomplish a fully functional web application is measurable.

    Smart Client Technologies over Web

    The Process

    1. Source technology C"b ' VWG UI using DL/BL interop to Source Technology
      The application will keep using the existing BL/DL layers as introp to C++ dlls, Delphi COM Exposed API (Technical Article) or a .NET to Java bridge (Starting Point Article) and only the UI is mimicked within a Visual WebGui project using the productive proven tools of WinForms.

      [figure7.png]
    2. Source technology - VWG Project
      The entire application is mimicked within a Visual WebGui project and .NET using the productive proven tools of WinForms.
      Gizmox has performed such experiments of migration; the "WebMail ProjectC"b,B is a web copy of the desktop version of Outlook 2007 (read more on WebMail project").

      [figure8.png]

    Considerations & Exceptions

    Except for the considerations and exceptions mentioned in the first section C"b,EWinForms based desktop applicationsC"b,B, there are two additional subjects derived from the VB history of the project:

    • The source desktop project coded on the source technology might use non-Thread-Safe win32 or native language API resources C"b," those should be handled as potentially dangerous to the multi user web environment.
    • Threading Model: Note that when interoperating or bridging components coded in a different technology there might be a difference in threading model; Consider using the STAThread attribute decoration above any method that is accessing VB 6.0 based COM/COM+.

    Summary

    Migration of smart client or other desktop technologies application to the web using Visual WebGui migration tool has the following advantages:

    • The application can keep using the existing BL/DL services -- no write or re-engineering is required.
    • UI concepts, design patterns and practices can be migrated as is.
    • Smart Client UI elements, API and behaviors are covered by the WinForms out-of-the-box so that migration of the UI to Visual WebGui is quite native.
    • The effort you have to make in order to accomplish a fully functional web application is measurable.

    Offered advantages for web or cloud deployments

    Now, let's assume for a second that we have got this thing working; according to the first claim on this document, we will still have to answer some questions in order to consider deploying our applications on the web or cloud:

    1. What clouds can host which web apps? - VWG runs natively over IIS and the .NET CLR so that you will only have to make sure that other backend systems in use are supported by the chosen cloud provider.
    2. How much will it cost us? What are we actually charged for deployed on cloud and how? Will this be a smart move economically?
      On the roadmap, VWG will enable assessment tools which will assist the developer to estimate and optimize cloud operational costs.
    3. Security wise, can we really expose our organizational apps to the web or the public cloud without severely risking the data security?
      The Empty Client paradigm shift (also referred as the Clever Client read more) makes VWG plain browser endpoints highly secured by-design (read more).

    Furthermore, you will have the same set of desktop like productive tools to further maintain and extend your plain web application in the future through which (if planned right) you will also be able to maintain and use the old desktop application without doubling the maintenance efforts.

    Conclusions

    If we can't reuse the same code base and run it on web or cloud, we might as well think of re-engineering and rewriting our entire application to fit the new, very different, web platform architecture. This type of move will probably cost us a lot of money and the time-to-market figures will also go up. On one hand, we will have the complete freedom to select our new development patterns and technologies; however, we will lose all of your code investments at once on the other one.

    I guess that if today's new development platforms would have innovate some straight forward development paradigms to help us cope with such tough mission, I would have never rejected this option completely as a reasonable alternative, however, since the latest development platforms require allot of new paradigms learning and all of them are not mature enough development paradigm wise, for example:

    Silverlight - no WYSIWYG UI designer, completely new object model, Client .NET differs from Server .NET, poor set of controls

    ASP.NET - involves a mess of both client and server code, no WYSIWYG UI designer, multiple possible clients with multiple standards

    It will be probably be much wiser to search for a way to emulate the same legacy code over the web or cloud.

    And now we can either choose to deploy our current desktop apps on the web without messing with code on one hand but paying allot for licenses and expensive hardware and compromise on performance and security (Virtual Client Option) on the other hand, or simply invest some initial effort in a reasonable migration project and be able to run almost the same legacy code on the web or cloud using Windows over Web option made possible by the "Empty Client" approach.



Comments

  • There are no comments yet. Be the first to comment!

Leave a Comment
  • Your email address will not be published. All fields are required.

Top White Papers and Webcasts

  • The mobile revolution and the need for mobile apps have created an unprecedented set of challenges for IT organizations. This eBook discuss these challenges and how organizations can address them by making their mobile app development processes more efficient and more effective.

  • Cloud computing isn't new, but it's still a hot topic in technology circles. Moving to the cloud has done great things for many businesses. When it comes to handling a basic business necessity, cloud computing has brought many improvements to overall business continuity. Using the cloud for DR makes a lot of sense for many, but it's not exactly the most simple concept. Read this eBook to find answers to all the key questions IT professionals have about cloud-based disaster recovery, and helpful info around the …

Most Popular Programming Stories

More for Developers

RSS Feeds

Thanks for your registration, follow us on our social networks to keep up-to-date