DataWindow to JDataPanel Conversion Online Demo
PB to Java White Paper
PB to .Net White Paper
Introduction
For many years PowerBuilder was one of the most serious and robust Rapid Application Development tools for Client/Server and n-tier development. Reliable high-performance PowerBuilder applications are deployed worldwide. Software firms invested in PowerBuilder frameworks, resulting in billions of PowerBuilder code lines written by thousands of trained developers. Unfortunately, PowerBuilder is now a niche player in the application development tool market. Even PowerBuilder\’s attempts to make inroads in the Web development market have not been very successful. The number of new installations is diminishing. PowerBuilder professional personnel are becoming scarce.
Enterprises with deployed active PowerBuilder applications need to both maintain their current systems, and provide solutions for dynamic changes and enhancements. Enterprises are at a point where they have to make a strategic choice: to continue building and updating applications in PowerBuilder where there is no future, or to move to another platform.
Remaining with PowerBuilder causes no upheavals but insures the widening of the legacy gap.
Moving to another platform is probably strategically correct but has serious implications:
- How to prevent the loss of the investment already made in the legacy applications
- How to reduce the significant cost of new application development.
- How to ensure a rapid and smooth migration from one infrastructure to another without disturbing critical systems; specifically how to integrate the new with the old.
More and more, organizations are being urged to move their PowerBuilder applications to a modern thin-client environment.
There are 3 main options:
- Face lifting (a strategy provided with the new PowerBuilder versions)
- Manual rewriting from scratch
- Automated conversion.
Face lifting uses the existing PowerBuilder application as a back-end, and therefore does not really move it to a modern environment.
Rewriting PowerBuilder applications from scratch is a very costly, time consuming process and may lead to a long learning curve for the end-users. Another significant point is that legacy applications and maintenance changes are not always well documented. Even when original system analysis documents exist, the risk of business knowledge loss is very high.
Automated conversion (with some minimal manual intervention) as a replacement methodology saves all the investment in business knowledge and enables further development and maintenance in the new modern environment.
This document presents the migration process suggested by MainTrend in order to meet all aspects and challenges of migrating PowerBuilder applications to full thin-client J2EE or .Net applications.
Post-Migration Environment
The migration target is a pure thin client environment based on J2EE or .Net and AJAX methodologies.
In case of J2EE target the server side can be any J2EE container / Java Application Server, running on any Java supporting operating system (IBM WebSphere, BEA WebLogic, Oracle Application Server, Tomcat, JBoss, Sybase EAServer, etc.).
The resulting application requires no client installation, except for a browser, and no operating system limitations. Currently supported browsers are Internet Explorer 6.0 and higher, and Firefox 3.0 and higher. The same browser software version has to be installed on all the client workstations. All the browser instances on the client workstations should have the same settings (security, JavaScript etc.).
This architecture provides centralized application management and does not require any additional software to be installed on the end-user workstations:
- Application changes that are made to the XML definition files (database access definitions, GUI definitions, etc.) are available immediately.
- Business logic changes, encapsulated within application server components, are available immediately after installation.
- The database is accessed from the application server components.
Migration Methodology
Migration to another platform requires a number of factors to be considered:
- Existing investment in legacy applications and the significant cost of new application development.
- Ensuring a rapid and smooth migration path from one infrastructure to another without disturbing critical production systems.
- Smooth and reliable transformation preserving all of the needed business logic. Maintaining legacy software business logic is the important part of an organization\’s knowledge storage. The more valuable the encapsulation of the business logic software is, the more complex the process of its evolution.
More and more organizations are looking to move their PowerBuilder applications away from the thick client, proprietary environment provided via PowerBuilder, into the n-tier thin client environment provided by J2EE or .Net. In order to accomplish this, some organizations have attempted to manually rewrite their PowerBuilder applications. Others have used conversion tools currently available on the market.
Organizations that have already moved applications, or who are investigating such a move, have had two options:
- To manually rewrite their PowerBuilder applications.
- To use conversion tools.
Each replacement methodology approach has its advantages and disadvantages.
- Manually rewriting can produce very effective resulting code, which may exactly match the target environment. On the other hand, it is a very costly and time-consuming process and may lead to a long learning curve for the end users and for the maintenance team. In addition, the risk of business knowledge loss is very high, in that legacy applications and the changes made to them are not always well documented.
- Automatic conversion is much faster, much cheaper, and also ensures that all the business knowledge is preserved. The resulting application is similar to the original one, so the learning curve for the end users and maintenance team is not as long as with a “rewritten” application. On the other hand, the resulting code is generated automatically. It may not necessarily be optimal for the target environment and for the specific application.
PowerBuilder as a migration source is the ideal case for a mixed approach.
A central element in PowerBuilder environment is DataWindow, a patented Sybase technology – very powerful object, concentrating almost all the data processing of a PowerBuilder application and almost all the visual representation of the application\’s data. The PowerBuilder DataWindow object is one of the main reasons for the success that PowerBuilder has achieved as a software development tool. Usually in a PowerBuilder application DataWindow objects consume more than a half of the application building efforts.
MainTrend approach to the conversion is to include DataWindow objects in the automatic part of the conversion, while making all the other PowerBuilder objects\’ conversion as flexible as possible to allow manual rewriting of the objects\’ methods. For .Net conversion target we use Sybase DataWindow .Net technology for PowerBuilder DataWindow objects.
Such a migration concept unites advantages of both approaches:
- The original application is automatically reversed engineered.
- All the DataWindow definitions are automatically converted to JDataPanel XML definitions and corresponding Java classes (JDataPanel framework is MainTrend\’s product for the J2EE environment; it is described here). In case of .Net target DataWindow definitions are used for DataWindow .Net objects.
- All the other PowerBuilder objects are parsed and converted to corresponding Java classes.
- All the target classes are generated in a match with the original inheritance tree.
- All the attributes and method signatures of the original classes are automatically converted.
- The bodies of all the methods in the generated classes are empty, with the original PowerScript code included as a comment. This allows for easier manual rewriting of these scripts and ensures effective resulting code, which exactly matches the target environment. This approach also prevents business knowledge from being accidentally dropped or omitted.
PowerBuilder to Java (PB2J) and PowerBuilder to .Net (PB2N) is MainTrend\’s software engine toolset and set of methodologies that take an application coded in PowerBuilder and generates target application source code with a minimal need for a programmer intervention. Java and .Net as target environments allow maximum platform flexibility. They have proven themselves to be superior technologies as modern business application tools for highly reliable applications.
This migration methodology provides:
- Rapid, accurate and valid way to migrate PowerBuilder applications to the new environment.
- Low assimilation costs for the new application
- The same productivity and more, in the new modern environment.
- Almost no limitations for the target server-side platform.
- Much lower cost and faster solution for the legacy applications\’ migration path.
- Flexible open-platform development environment. The applications can be further developed with the most cutting-edge development tools
- Cross-application code reuse enabled environment and reduced maintenance costs.
- Seamless integration with modern technologies and new approaches.
Migration Process and Solution Architecture
Generally the migration process has the following steps:
- Detailed analysis. Selecting the target server-side platform
- Verification and fixing of the source application
- Export of all the PowerBuilder objects of the application to be migrated
- Reverse engineering of the original application
- Code generation
- Manual rewriting of the application classes\’ method\’s code
- Preparing test environment
- Database migration (if a new database platform is chosen)
- Unit testing, including required database connection for the data access layer objects
- External links migration (if any)
- Code integration and thin platform adaptation. Application restructuring required for the thin client conversion model
- Database integration and changes required for the chosen database platform
- General graphical design; fine tuning of the resulting GUI in line with customer standards
- Application integration testing and corrections
- User acceptance
- Building the production environment and implementing the new application in production
- Trainings for the customer\’s developers
The conversion itself is covered by steps 3 through 6 and uses PowerBuilder Conversion Suite.
PowerBuilder Conversion Suite consists of these parts:
- For Java targets: J2EE-based JDataPanel framework that allows future flexible and reliable development in the new Java-based environment, and which also includes an independent product for rich Form/Report design – MainTrend\’s JDataPanel Designer. The framework supplies all the needed functionality that PowerBuilder DataWindow objects have, including database access, forms and reports. JDataPanel can be also used to create new Java applications, not just to convert existing PowerBuilder applications.
- The PowerBuilder Converter itself, which translates each PowerBuilder application into a set of Java or .Net and XML modules.
- Conversion and development methodologies, including best practices for the most effective manual completion and enhancement of the resulting applications.
We use the PowerBuilder “library export” functionality to obtain all the sources of PowerBuilder objects for the specific PowerBuilder library set. After the reverse engineering stage the code generation stage comes. All the DataWindow definitions are automatically converted to JDataPanel XML definitions and corresponding classes. All the other PowerBuilder objects are parsed and converted to corresponding target classes. The bodies of all the methods in the generated classes have the original PowerScript code included as a comment. These methods are then rewritten in the manual completion stage, which also includes GUI tuning (based on the customer\’s requirements) and database access tuning.
The PB2J / PB2N toolset uses a sophisticated concept of multi-level embedded parsers and template-based code generators. This concept allows use of different parsers for different parts of the scripts and objects\’ types, and improves the conversion performance.
Visually the conversion process can be depicted in this manner:
Conversion Services and Pricing Model
MainTrend offers an automated conversion service that lifts PowerBuilder applications to Java/XML technologies while preserving the business logic base and user interface investments.
Most of the work can be done remotely. This reduces or eliminates most of the costs associated with travel to and accommodation at the customer location.
The manual part can be divided between MainTrend and the customer or a third party conversion partner.
Varying options can be applied to the conversion projects, from full conversion to different “reverse engineering” stages and automatic generation of scripts to be used by customer\’s developers as a tool for business logic capture, etc.
The business model can also vary, from fixed price projects to hourly based consulting. A mix of type models for different stages of the conversion is also possible.
Questionaire Form
To be more precise in our estimations we need your answers to the following questions:
| 1. |
What PowerBuilder version do you use for your application? |
|
| 2. |
What framework do you use for your applications (for example, PFC – PowerBuilder Foundation Class Library)? If so, please add your framework measurements to your application measurements below. |
|
| 3. |
What is the total size of your applications ( in Mbytes, for all your “pbl”s )? |
|
| 4. |
Total number of DataWindow objects? |
|
| 5. |
Total number of Window objects? |
|
| 6. |
Total number of UserObjects? |
|
| 7. |
What is the average number of methods for a PowerBuilder object in your applications? |
|
| 8. |
What is the average size (in lines) of methods? |
|
| 9. |
What database (and how many databases) do you use? |
|
| 10. |
Total number of tables in all your databases? |
|
| 11. |
Total number of views in all your databases? |
|
| 12. |
Total number of stored procedures and functions in all your databases? |
|
| 13. |
Are database procedures used as data sources for your DataWindows? |
|
| 14. |
Total number of external applications called from your PowerBuilder applications? |
|
| 15. |
Is your business logic mostly incorporated within your PowerBuilder applications, or located externally? What is the average complication of your external logic (from 1 to 10)? |
|
| 16. |
What will be your end-user environment ( e.g. MS Windows, X-Windows etc. )? |
|
| 17. |
What will be your server-side environment ( operation system, database, application server etc. )? |
|
| 18. |
What will be your network topology? |
|
| 19. |
What is your estimation for the overall quantity of end-users? |
|
| 20. |
Are your personnel familiar with Java environment and, if so, on what level? |
|
| 21. |
Are your personnel familiar with .Net environment and, if so, on what level? |
|
| 22. |
Required target platform: J2EE or .Net? |
|
| 23. |
What is your schedule for the project? |
|
| 24. |
Additional notes |
|
Your contact information: |
| Email |
|
| First Name |
|
| Last Name |
|
| Skype |
|
| Phone |
|
| Title |
|
| Organization |
|
| Country |
|
Based on this information we can make ( though very preliminary ) estimation of the needed efforts and time schedule, and build right model for the conversion project. More accurate estimation requires PowerBuilder applications and database structure to be thouroghly analyzed.
Thank you for your interest in our services. We will be glad to assist you in maintaining the future of your PowerBuilder applications.
