PowerBuilder to Java/HTML5 Modernization
by John Browne, on Oct 20, 2015 10:31:44 AM
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.
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.
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.
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 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.