evolution framework

Case Study: Migrating Desktop Applications And Teams To Java Web Technology

Summary

This article will show what you need to do if you have enterprise desktop applications and a desktop development team that you want to migrate to the web in the shortest time possible and as easy as possible.


Table Of Contents

Based on a true story
Desktop vs web development
Old elegance of a desktop user interface
Complexity of a web user interface
Smart business decisions
Protect your business know-how
Retain your people
Don't pause your deliveries
Don't start from scratch again
Choose a complete framework for efficient development
Focus on solving business issues, not technical issues
Choosing a framework
Why Java?
Why Evolution Framework?
The great solution: desktop-to-web converter
The migration strategy when having a converter
Step 1: Start with web development - TODAY
Step 2: Stop using the converter for new web forms
Step 3: Migrate desktop applications to the web automatically
How the converter works?
Converting form layout
Converting form code
The converter and web engine under the hood
Conversion sample
Old desktop form
Using the converter
The converted form
The converted form running
Conclusion

Based On a True Story

This is a true story of an IT department in one of the largest Croatian banks that used to develop desktop applications. The team was using a popular 4GL technology that enabled them to develop desktop applications either having a graphical user interface (GUI) or a text mode user interface (TUI).

One day, the popular cloud concepts came in and the top management decided to move enterprise applications and development to the web.


Figure 1: Typical impression of desktop developers dealing with web technologies

Desktop Vs Web Development

The biggest difference between developing desktop and web applications is in the way the user interface is built and how it works.


Figure 2: Technical difference between desktop and web development


Old elegance of desktop user interface

When you are developing enterprise desktop applications you will design a user interface for your form using a visual editor provided by the desktop technology of your choice. Maybe you will use Visual Basic, or Delphi, or Visual C++ or some 4GL tool like Panther (Prolifics).

When it comes to writing the code for the form, your code will typically handle events on the form. The very first event that you will handle is usually the one that happens when the form is displayed to the user for the first time and you want to initialize it. Later on, the user will click on a button, or double-click a row in the grid, or press a keyboard shortcut, and your code should handle these events interacting with a database or, perhaps, external services in a multi-tier systems.

Complexity of a web user interface

If you are developing web applications, the user interface usually becomes a very complex story. Most of today's web frameworks will not provide you with a visual editor for the form layout, instead you will have to write the form layout character by character, tag by tag, using HTML, CSS and JavaScript code. Some web frameworks do provide visual editors that generate HTML code, but in the end, you will still have to know those web technologies well, because you will still end up touching up the HTML code manually or your web server code will have to generate HTML content during runtime. However, this is only half the story about the user interface.

The second part is communication. Web architecture requires that you use HTTP to send your initial form layout to a web browser. Then, when a user clicks a button you will have to use AJAX technology in the web browser to call your event code on the web server to interact with the database. Finally, you will have to return the update information from the web server to the web browser to update the grid with data rows or input fields with new values.

Creating a user interface in such a way for small web applications is a good and flexible way to go, but for enterprise applications that consist of hundreds or thousands of different forms such development is a very slow process prone to errors and, in the end, very expensive and hard to learn.

Smart Business Decisions

The management of the IT department from our story came across these problems and were thinking what to do. So, to start, they made a few very smart decisions.


  • Protect your business know-how

First, they decided that they wanted to protect their business know-how. That meant that they would probably use outsourcing partners to handle new technical challenges. However, they didn't want to outsource the development of business functionalities because that would also mean giving away knowledge about company processes and plans, and outsourcing partners could eventually sell that business know-how to the competition in the form of a software or, simply, information.


  • Retain your people

The existing development team was too precious to be replaced with a fresh new team because of their advantages:

- they had huge business know-how, having worked in the company for years,
- they had a good relationship and communication with application users across the company,
- they are the only ones who are versed in existing business applications and can fix or upgrade them quickly,
- they were very efficient in desktop development and were excellent as a team.

  • Don't pause your deliveries

Keep in mind that the existing development team had been maintaining current enterprise applications and spending time on upgrading them because the company processes were evolving. So, they didn't have a lot of time to learn all the new complex web technologies quickly. Is there a way to learn web technologies quickly and start delivering new web applications without slowing down current development and delivery? And all that without hiring new people which would increase expenses?


  • Don't start from scratch again

What about current enterprise desktop applications? It will be harder and harder to maintain them over time when old technical knowledge will be lost and old software or old hardware support will be discontinued. Who will rewrite these applications to a new web technology? They had thousands of desktop forms already in action. Some applications are still being upgraded very often and it would be nice to continue improving and upgrading them on web technology, not re-implementing them again from scratch.


  • Choose a complete framework for efficient development

The perfect web development framework that they wanted to find had to be powerful, built for enterprise environment and must have a visual editor for forms. Such a web framework also needs to have all new popular features, required in modern enterprise web applications, ready out of the box. These days users demand not just grids with data and forms with input fields but also document management, workflow and task management features, reporting to different file formats, integration with e-mail and web applications which must also work on mobile devices and tablets.


  • Focus on solving business issues, not technical issues

Your web framework must also hide the complexity of web architecture and web technologies, because business programmers must be focused on solving business issues and not on solving technical problems in the web environment. It was impossible to find an open source framework with all these features out of the box.

Choosing Framework

After making all these decisions the management tried to find a way to accomplish these aims. First they had to decide which technology and then which web framework to use. Starting from scratch would take too much time.


Figure 3: Evolution Framework tools


Why Java?

Java is a proven technology for development of enterprise level web applications. It is free to download and there is a huge Java open source community with many available solutions. This is why the top management decided to use Java as their web technology.

Why Evolution Framework?

During that time, Evolution Framework had already grown into a mature product and seemed as a promising candidate. It was specialized for the development of modern enterprise applications focusing on efficient desktop-like web development. Programmers could skip the learning and using complex web technologies part, and still quickly deliver web forms.

The Great Solution: Desktop-to-Web Converter

When they were thinking of how to move the existing applications to the web, they came up with an even bolder idea. How about making a software converter tool that could convert old desktop forms to web forms automatically? Was it possible? If you could create such a tool, it could automatically convert thousands of old form layouts and thousands of lines of old code to the web environment. This could save the developers years of work on rewriting old code.


Figure 4: Desktop-to-web converter

Yes, it was possible! And it didn't just allow them to convert old code but such a tool also enabled one great migration strategy for developers.
Keep reading.

The Migration Strategy When Having a Converter

If you have an automatic desktop-to-web converter, you can create a great migration strategy that consists of 3 steps.

Step 1: Start With Web Development - TODAY

If you have a desktop-to-web converter it is possible to start with web development almost immediately. First, you have to setup a web development, testing and production environments, which is easy to do with Evolution Framework because it has a nice visual system overview screen and you don't have to bother with a bunch of configuration files.

Then, a programmer will write new forms in the old desktop technology, but when the desktop form is finished the programmer will use the desktop-to-web converter to convert the desktop form to a web form. This way, desktop programmers will be able to start delivering web forms and web applications instantly.

Step 2: Stop Using The Converter For New Web Forms

The desktop-to-web converter is not just a tool for converting old forms to web forms. It is also a learning tool. After converting desktop forms, developers can compare the old desktop form code with the new Java form code and learn the syntax more quickly. In our case - the new code was very similar to the old code. Have a look:


Figure 5: New converted Java code on the left, the old desktop code on the right

To make the converted code so similar to the old one, you have to re-implement some of the old commonly used API functions from the desktop environment to the new Java web environment. Usually it is an easy task when you have a good web engine under the hood.

Therefore, after the developers learn the new Java code syntax and get familiar with Evolution Framework's visual editor, they can stop making old forms and start designing form layouts directly in Evolution's' visual editor, whilst writing Java code in Evolution Framework using e.g. Eclipse for Java as a popular IDE.

Step 3: Migrate Desktop Applications To The Web Automatically

The final step is to move the old applications to the web environment. To convert old desktop forms to web forms you will use the desktop-to-web converter and, usually, you start with top priority candidates for migration. Maybe the ones that will soon be out of old software or hardware support, or you can pick the ones that need to be upgraded anyway and you want to also use some new modern technical features available in Evolution Framework.

Sometimes, the conversion of old applications is the first step in such a migration project and afterwards you can start delivering new web forms.

How The Converter Works?

Let's see what the technical challenges are when converting desktop forms to web forms. In desktop technology, every form has two main parts: the layout information and the form event code.


Figure 6: The process of conversion


Converting form layout

Layout information for a single form is usually written as a binary or text file. Such a file contains a list of all controls like buttons, input fields and grids which appear on the form along with their initial property values like x and y position, enabled/disabled, visible/invisible, etc.

The first step in creating the converter was to make it handle the conversion of this old layout information to the new layout information written as a visual editor form file which is a part of Evolution Framework. After the conversion, you can use the visual editor to modify the form layout and add some more controls to the form, even some advanced ones that didn't exist before in the old environment.

Converting form code

Desktop event code for old desktop forms is an actual code that consists of functions that handle specific events on the forms like form initialization, button click, double-click on the row, field validation after the focus is lost, etc. The second step in creating the converter was to make it handle the conversion of such event code. The converter must analyze the old code and make equivalent Java code.

You also have to convert some old commonly used API functions available in the old desktop framework so that the programmer would have almost the same look and feel of the Java code in the web environment.

The Converter And Web Engine Under The Hood

The steps described above seem kind of obvious, but to get all that actually working after the conversion, you must have a web framework whose web engine logic is very similar to the desktop engine's logic. Such a web framework must have the following features implemented:

  • it must be capable of completely rendering the initial HTML form in the web browser, based on the layout information from the visual editor
  • it must render Java code for each form with all the controls on the form so that the programmer's form event code could easily communicate with the controls on the web server in Java
  • it must provide mechanisms that will send user events from the web browser to the web server directly via AJAX, so that the Java form event code could save the data entered by the users to a database and/or read the data from the database and update form controls
  • it must provide mechanisms to return event results from Java code on the web server back to the form in the web browser upon updating form content

This way, programmers will never have to bother with HTML, CSS, JavaScript, HTTP and AJAX, and can focus on writing event code and interacting with databases and other external business systems.

Conversion Sample

Let's see all this in action.

Old Desktop Form

Here is a sample of the old desktop form in a visual editor provided by the desktop technology that the IT department was using:


Figure 7: Old form in Panther IDE

Here is that same form in action, having a text user interface.


Figure 8: Old TUI form

And here, again, is that same form in action, but with a graphical user interface.


Figure 9: Old GUI form

Using The Converter

The desktop IDE had an option to export a form to a single file. That file contains layout information and form event code.

The desktop-to-web converter tool is a part of Evolution Framework and it is a web based tool. This web application is run on a local web server and can access exported form files in a local folder, here is a sample:


Figure 10: The desktop-to-web converter

When you run the converter - it will create three things:

  • first, it will create an XML file with the form layout which is an input file for Evolution's visual editor so that you can modify the form layout in the editor and add new advanced controls later
  • then it will generate a Java code with all the controls on the form. This code is a Java "model" of the form that the programmer will communicate with either to read input field values, fill the grid or hide buttons. The programmer will never modify this code, it will be generated again every time the form is modified in the visual editor
  • finally, the converter will convert the original form event code to the Java code which will look almost the same because of the same API already implemented additionally into the framework

The converted Form

A sample of the converted code can be seen above in the article and here is the final form in the visual editor:


Figure 11: Converted form layout in Evolution Framework's visual editor

The Converted Form Running

Here is that same form in action, after some redesign in the visual editor:


Figure 12: Web form running, after some redesign in Evolution Framework's visual editor

Conclusion

Migration from desktop to web development without a converter is a very long and expensive process. To enable automatic migration you must have a web framework, like Evolution Framework, that supports such a technical step.

Unlike many other Java web frameworks, Evolution Framework is a complete solution specialized in building modern enterprise web applications. It is not just a development environment and a set of API's to write code - instead, it is a set of actual visual tools that you can use in all phases of development: design, programming, deployment and monitoring.

Having document and workflow management features out of the box, Evolution Framework will help you deliver rich and powerful enterprise web applications to your end users.