Migrating Gen GUI client-server applications to the Web
Article ID: 27829
Updated On:
Products
Issue/Introduction
What are best practices to follow when migrating distributed CA Gen GUI client-server applications to a Web environment.
Resolution
A New Type of Architecture
With the move from a GUI client-server environment to a Web client-server environment, the biggest thing to realize is that the "main brain" of the client application no longer resides on the end-user's computer. For GUI design applications, data validation and some initial processing could happen "on the spot" before anything got transmitted across the network, and therefore the more of this you did up-front, the more efficient your distributed application was. With Web client development every event that gets triggered, and some portion of the data validation that gets done, requires a round-trip across the network from the end-user's browser window to the Web Application Server and back. Consequently, efficiency in terms of limiting the trips back and forth to the Web Application Server, and accomplishing more with each trip becomes more important.
One Model = One Context = One .EAR File
With earlier types of platforms, you might have had different areas of your enterprise application structure defined in separate models - a model for inventory, another for purchasing, another for security, and so on. In the worlds of COBOL and C, this was no problem, as you could generate the different areas and dump them all in the same directory and still have one cohesive application. With J2EE, this has all changed.
With the advent of the .WAR (Web Application aRchive) file and the .EAR (Enterprise Application aRchive) file, J2EE attempts to encapsulate your entire application into its own context or "bubble", so as to insulate it from other applications running on the same Web Application Server. A Gen model and a J2EE context are roughly equivalent. In the above example, inventory is now insulated and separate from purchasing, security, and so on. If these things are truly separate and distinct, this might not be a problem for you. But if some interaction was intended, you may need to rethink and combine some models to achieve the common context that J2EE requires.
Web Application Servers - Equal but not the Same
Websphere, JBoss, and Weblogic are just a few of the many Web Application Servers available today that are J2EE compliant. This means that a .EAR file you create with Gen can be deployed to any one of them and it should work correctly. While all of them will work equally well from that perspective, there are differences between the different brands that should be studied and evaluated before settling on the Web Application Server that will work best for you in your particular environment. Some areas to investigate might be the scalability and capacity of the Web Application Server, how it implements security, and how external resources like databases and external libraries are defined, among many other things. Once you've made a decision about which Web Application Server is for you, a bit of study will be involved to learn how to best configure and optimize the Web Application Server to meet your needs, describe your external resources to it, and deploy, publish and maintain your applications.
Conclusion
The differences in architecture, application contexts, and the various Web Application Servers you could choose all contribute to the complexity of this transition. However, with a bit of upfront planning and thought, migrating to the web environment can bring many great benefits to your application and organization.
Feedback
