PowerBuilder to Java/HTML5 Modernization

The PowerBuilder to Java/HTML5 Migration is the leading way for migrating legacy PowerBuilder code to the Java framework and the most modern HTML5 portable UI. Our automated migration technology has migrated billions of lines of code, and is used by hundreds of thousands of developers.

PowerBuilder Conversion Target Architecture

Mobilize.Net PowerBuilder to Java/HTML5 migration tool migrates PowerBuilder apps to a Web application that follows an MVC architecture using the Spring MVC framework on the server side and follows an MVVM architecture on the client side.

The following diagram shows a high-level view of the proposed architecture.

The UI of the migrated application is generated using HTML5, CSS and JavaScript, using several libraries including AngularJS and Bootstrap. Every window and data window in the original application has a corresponding view file.

The client side of the application contains ViewModel objects for each one of the windows of the application. These ViewModel objects are created using JavaScript (in JSON format) and these objects are bound to the HTML controls of the UI using AngularJS.  

On the server side, the converted application has a set of Spring MVC controllers that represents each one of the windows of the original application; these controllers have endpoints to handle each one of the different interactions of the windows, and receive and return data in JSON format.

The communication between the client and server sides is performed by a series of JavaScript libraries developed by Mobilize.Net. They use JQuery to process the events on the client side then determine the changes to the ViewModel objects and send those changes to the server via Ajax requests using JSON objects.

Besides the controllers, on the server side the application has model objects that represent the elements of each one of the windows and are equivalent to the ViewModel objects on the client side. There is a set of Mobilize.Net libraries written in Java 1.8 that take care of the synchronization of the objects sent from the client side with the models in the server-side. They also handle logic to create instances of these elements and retrieve the necessary objects for each user’s session. The source code for these libraries is part of the migrated application.

Once a request from the client side is processed by a controller on the server-side, instances of the models for the current windows are created and the control passes to the business logic layer, where the actual logic of the application is (this is the logic that comes from the event handlers and functions of the original application). This logic interacts with the model classes instead of the user interface.

The models on the server side replicate the hierarchy defined in the original application.  There is a set of libraries that replicates the built-in PowerBuilder functionality (things such as the binding of controls to elements in the data source, the life cycle of events of a data window and tracking of changes in specific records).

Additionally, during the conversion of the application all the logic that accesses the database is moved to a new layer that uses JDBC to connect to the database and execute any existing queries. This layer exposes a method for each one of the different queries in the application and is the only set of classes with direct access to the database.

Application UI

As described in the previous section Target Architecture, all visual elements of the application are converted to HTML5 components that provide equivalent functionality.

The application runs as a single page application inside a web browser. The use of a single page application means that there won’t be full updates of the browser when new elements are added to it and the modifications will be made dynamically, loading elements using Ajax with the help of different JavaScript libraries.

Server-side MVC

The application is generated as an MVC application using the Spring 4 design pattern.

A model class is generated for each one of the Windows and Data Windows in the original application, and this represents the objects transferred between the Client and the server side of the application.

The rendering engine from this framework is used to dynamically generate the corresponding CSS and HTML elements for the views. As with the models, there is a view file for each of the windows or data windows in the original application and these are returned based on the requests performed by the client.

The application controllers are generated as the endpoint for the requests from the client. There is one controller for each window in the original application with different methods for the different actions that can be performed by each window or data window. The controllers are configured to receive and return data formatted using JSON, effectively working as a REST services layer.

Helper Classes and Runtime Libraries

Since the original application is a desktop application it has many differences from a web environment. To deal with these differences, Mobilize.Net delivers as part of the application a small set of libraries to perform tasks that are not directly related to the business logic or flow of the application.

The functionality in these libraries includes:

• User settings management
• Management of each user’s state/session
• Automatic binding of data sets with model properties
• Life cycle of data windows (triggering of events in the corresponding order)
• Synchronization of models between the client and the server
• “Lazy” creation of objects and properties of the models
• Automatic instantiation and association of models and corresponding logic classes
• Base classes for models of common controls (buttons, grids, dropdowns, etc.)

All these elements are part of the source code in the migrated application and won’t have any dependency on proprietary elements. You can learn more here.