In-Depth
Apps of Steel
by Mark Buchner
We all should know by now, that the only way to lose weight is to exercise more and eat less. But, despite the fact that we’re smart, we’re still inexplicably prone to fool ourselves into believing that a glitzy-advertised magic pill or fad diet will effortlessly reduce our weight, while we continue to watch TV and eat fast food.
Modernizing applications is similar.
We all know modern, well-designed applications are healthy for our business and ourselves. But, it takes much willpower and effort to shape up and to tune up our applications. But, that won’t stop us from wanting to believe some magical story about tool "x" or product "y"—which will transform our applications easily for money alone.
Don’t believe it. Modernization takes willpower and hard work. But, it’s good for you and may save or prolong your life!
The effort starts by recognizing that the root problem deals with the changing of the application architecture. Modern applications require a distinct separation of interface, processing logic, transaction logic and database access. To boot, these interfaces must adhere to standards so that they can operate in an open and heterogeneous environment.
What are the architectural differences?
Legacy System (Single Tier). These are traditional systems, usually written in COBOL or RPG that combine all elements for the program (interface, processing logic, data) into a single set of programs.
Client Server System (Two Tier). These represent applications, in favor during the ’80s, which tied a "fat" client (typically using Microsoft OS and tools) to a relational database system using middleware.
Web Model (Three Tier). This model provides independence from the client OS, by separating the interface from processing logic. HTML, Java, XML and JDBC represent some of the open standards.
n-Tier. This optimal model permits highly distributed, heterogeneous processing and provides for better division of workloads between interface designers, application developers and enterprise data and transaction analysts.
To move from a legacy system to a Web model or n-tiered model requires knowledge about the following:
- The redevelopment design starts with the user interfaces today and means conducting a screen-by-screen assessment of how the screen would translate to an e-business interface while retaining/improving its usability and performance. The designer will find that the biggest decision is whether the screen can be "straight HTML" or whether it represents a complex graphical interface, which will require extra controls. Tools can help, but not replace this work. For development of the GUI controls, the current most popular method is Java swing components, which are part of the Java Foundation Class. This hard work becomes fun, once you master the screen conversion techniques—maybe working with college kids who use HTML tools. Swing is more complex, requiring tools, such as VA Java and more sophisticated programming. It also has performance impacts for when the swing objects are downloaded as applets.
- For those screens that cannot or will not be modernized, the "lazy" approach is to use Host On Demand (HOD), WebFacing or various screen scraping tools. This does not allow you to achieve the new architecture, but does provide immediate relief.
- The second component in our architecture is the application server. This is typically represented as Java servlets, built with an object framework. This will require an e-business infrastructure that addresses security, availability, scalability and a software server to administer the servlets. This is usually a new system, with fast processors. In the IBM case, the software chosen would typically be WebSphere (WebSphere Application Server or WAS). Building this Java-based framework is new to most customers, so customers will need to educate, inform, outsource or get mentoring as the projects move along. The chosen IBM development platform is Visual Age Java.
- The servlets will need a robust messaging system to relay their requests and responses back and forth to the transaction server. There are many solutions here—most are just plug-in. MQ Series is the most widely recognized and works everywhere. XML is more complex and comes into play when there are data definition dynamics.
- The transaction system represents the back end. If you want to reuse code … you can, but users will have to restructure their code. AS/400 users are greatly rewarded for doing this, because it changes applications that are considered "interactive" (and this requires the expensive Interactive Feature cards) to be batched. Using this method, the code will need restructuring, but the data will not. The existing legacy skills have a very important role in the new architecture.
- More adventuresome or "open" customers will utilize Enterprise Java Beans to create or replace transactions that have been written with the legacy tools. They will also design and use SQL-based databases, leveraging their features like stored procedures and triggers.
Mark Buchner is President and founder of ASTECH Solutions Inc. (Aurora, Ontario, Canada). Contact him at mbuchner@astech.com.