Mobilize.Net's automated migration tools and services move your PowerBuilder apps to modern web architecture and languages.
You can stop worrying about finding PB resources and get into the 21st century with your code. Say goodbye to PowerBuilder forever.
Mobilize.Net's PowerBuilder to HTML5 migration tool transforms PowerBuilder code to web applications using either ASP.NET/MVC or Spring MVC framework on the server side and MVVM architecture on the client side (choose between faithful or responsive design options).
Open standards, modern platforms, and true OOP are your new paradigm, not ancient 4GL obscurities.
Choose Java or Microsoft
Are you a Java shop?
Implement your web app with Java Spring MVC server code.
Prefer Microsoft bits and pieces? Choose the ASP.NET/MVC option.
Either way, you get out of the PowerBuilder trap and into a modern set of languages and frameworks, with a Single Page Application (SPI) on the client and a scalable, cloud-ready back end.
The PowerBuilder application is migrated to a web application using an MVC framework (Spring or ASP.NET) on the server side and MVVM architecture on the client side.
The following diagram shows a high-level view of the architecture.
Every window and data window in the original application has a corresponding view file.
On the server side, the converted application has a set of 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 client side is pure HTML with CSS, with a faithful-to-the-PowerBuilder-UI or--by modifying the generated CSS--a more modern responsive design. The implementation is compatible with all modern browsers and does not rely on any binary libraries or plug-ins.
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. Mobilize.Net libraries written in Java 1.8 or C# take care of the synchronization of 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. Additionally, during the conversion of the application all the logic that accesses the database is modified to use JDBC or ODBC to connect to the database and execute any existing queries. This 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 above, 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 MVC design pattern. For Java shops Spring 4 is used; for Microsoft shops ASP.NET/MVC is used.
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.
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.