When we hear the term application modernization, the immediate image that comes to mind involves modernizing twenty-five year old critical business applications written in COBOL. While this is still true and represents the bulk of work in this field, there are other growing areas of application modernization that businesses undertake. These include migrating more recent heavy-weight legacy applications based on technologies like JEE and Oracle Forms to the newer light-weight Spring Framework. Another emerging modernization area involves moving from older web user interface technologies like JSP to newer more robust technologies like Spring Web Flow, Adobe Flex, and Google Web Toolkit (GWT). Modernization also involves updating the web layer to support mobile devices like the iPhone. Regardless of the application modernization area, MyEclipse for Spring provides tooling to support a rapid migration strategy.

Modernizing Existing Legacy Systems

COBOL Systems

Interestingly, reading through the plethora of online technology sites, it’s easy to get the impression that today’s information systems are almost all web applications using Java or .Net on the back-end. The reality, of course, is that the bulk of critical business applications remain in the world of COBOL – and there are no signs those systems are going to change dramatically in the near term. What is changing with an elevated sense of urgency, however, is the recognition that businesses need to define an application modernization plan that preserves and renovates their critical business processes while at the same time reducing the operating and maintenance cost of their aging existing systems.

From a high level perspective, the plan involves starting with an “as is” analysis of the current system – e.g., understand the complexity, structure, business rules, nature, and intended use of what is typically a loosely understood and largely undocumented system. The next major step involves defining the path for the “to be” system. In most cases, the modernization migration path involves a practical incremental approach. In this incremental approach, we start by defining, publishing, and using key business functionality from the existing system through web services. Then, we develop individual functional areas with Java/Spring and migrate the application in functional blocks in a timeframe that the business and technical teams can handle.

Oracle Forms Systems

The process for migrating from an Oracle Forms system to a Spring Framework system will be similar to the COBOL legacy system migration strategy. However, the migration effort should be easier due to a probability that the system software will be understood for the most part and has documentation. The functional areas may be a little tricky to separate as Oracle Forms relies heavily on PL-SQL for implementing business and validation logic. For Oracle Forms, the web services will usually be thin wrappers that call the PL-SQL stored procedures.

JEE Systems

The process for migrating from a JEE system to a Spring Framework system will be similar to the COBOL legacy system migration strategy. However, the migration effort should be easier due to a probability that the system is understood for the most part and has documentation. Also, the developers will already understand Java.

Using MyEclipse for Spring in the Migration Plan

MyEclipse for Spring provides tooling to accelerate the “to be” migration strategy – for both scaffolding the web layer and using the web services to access the existing legacy system, as well as, developing the functional areas for migration to Java/Spring solution.

Incremental Migration – Using Web Services

After web services are defined and exposed, we use the WSDL import capability of MyEclipse for Spring to quickly generate the Spring and JAX-WS infrastructure to support calling the web services. Once the web service infrastructure is generated, we use the MyEclipse for Spring scaffold capability to quickly scaffold any of a variety of web layer implementations (e.g., Spring MVC, Spring Web Flow, Adobe Flex, GWT, and iPhone) for any of the Java Beans created during the WSDL import process.

Incremental Migration – Developing Spring Services

Another feature of the WSDL import process is the generation of “contract-first” Java package shells. When the WSDL import process completes, we have code shells for Spring Services and JUnit test classes that would be implemented and tested by Java developers. MyEclipse for Spring also includes code assistants to help developers create and maintain Spring annotations for their Spring Services. Once the code is completed and the business is ready, only one line of code needs to change to switch from using the web service provided by the existing legacy system to the new Spring Service.

Modernizing the User Interface

For the desktop

This area of modernization has become more popular as we see robust RIA solutions mature in the marketplace (e.g., Adobe Flex, Spring Web Flow, Google Web Toolkit, etc.). MyEclipse for Spring simplifies this modernization process through its scaffolding capabilities. Starting from a variety of sources including data schemas, JPA entities, and Java Beans, developers scaffold the web layer with the new user interface technology. From there, developers use the scaffold as either a starting point for building the complete user interface against the back-end or as a reference implementation template for coding the user interface with the chosen technology.

MyEclipse for Spring Scaffolding Wizard

For mobile devices

Similar to its help for desktop web applications, MyEclipse for Spring simplifies modernization process for the iPhone through its scaffolding capabilities and for other mobile devices with small changes to context files and style sheets. Again, developers use the scaffold as either a starting point for building the complete user interface against the back-end or as a reference implementation template for coding the user interface with the chosen technology

iPhone Scaffolding with MyEclipse for Spring

Try it Yourself

MyEclipse for Spring is available for a free, 30-day trial. Accelerate your application modernization process by downloading from http://www.myeclipseide.com/module-htmlpages-display-pid-4.html.

Although there are several important technical areas of concern when developing production-ready software, its success fundamentally depends on having running code that implements the original conceptual ideas and functional requirements.  On the surface, this seems to be a straight forward and well understood problem to solve.  Talk to the users (or their proxies, the business analysts) to capture the conceptual ideas and requirements – then translate them to design and code.  How difficult can that be? Seriously, the more complex and interesting problems will involve addressing the technical concerns of scalability, availability, maintainability, security, etc – right?

Of course, those of us who spent decades in this field learned first-hand that moving from conceptual idea to running code that reflects the functional requirements involves a lot of moving parts.  This includes working with a diverse set of people and a lot of “I probably won’t know or understand what I want until after you build it” reality, which make it a very complex problem to solve.  The field of software engineering does a nice job of breaking down the basic process elements for attacking the problem.  Regardless of the development methodology you use – from the older waterfall through the newer agile variations – they all involve some level of define, design, build, deploy, and test processes.

Bridging the Disconnect between Conceptual Design and Running Code

Looking back at years of real projects and the lessons we can take away from them, it becomes apparent that we have to address key failure points as early in the software development lifecycle as possible.  The first failure point is typically traced back to vague, misinterpreted, and missing requirements.  Its downstream impact is increased time and money required to address the disconnect from what the user actually wanted and the delivered application, which kills the benefits projected and in effect reduces the success of the project.  Typically, these disconnects only come to light after the application is built and the user actually uses the running code.  This is the genesis for the area known as functional prototyping.  The premise is simple enough – inject the opportunity to validate the functional requirements of the system before actually investing the time and money to build the system.

This area of software engineering has had some level of success, but continues to suffer real uptake in the industry.  This is mainly due to the time consuming nature of creating what is essentially a throw away mini-project during the conceptual phase of development using the current tools available in the market. Pure agilest will also argue that functional prototypes become less needed as you reduce the application release cycle times. In essence, these mini-application releases serve the same purpose while also producing usable code.  On the surface, this seems a reasonable argument.  Interesting enough, the argument can be flipped to say non throw away functional prototypes embed the value of agile principles – focus on producing software often and early – within the waterfall methodology for the complex systems.

Using Scaffolding to Create Functional Prototypes

This is where MyEclipse for Spring provides a modern light-weight solution that makes sense for both simple and complex projects.  Use the scaffolding capabilities to produce quick functional prototypes during the conceptual phase of the software development life cycle.  The tooling provides full web application scaffolding from a variety of sources including data schemas, JPA entities, Java Beans, and WSDLs.

The most common functional prototyping approach is validating a functional area defined by a set of tables in the data schema.  In this scenario, a business analyst with minimal technical skills could run through the scaffolding wizard and generate a working CRUD web application for the selected tables.  However more often, a business analyst or set of business analysts are paired with a developer to quickly validate the domain and the expected functional interactions.  The beauty of this approach is the minimal time required for the users (or more likely, their proxies the business analyst) to validate and update the functional requirements.  It typically takes minutes to scaffold, followed by short iterations to update the domain and the functional requirements.

Functional Prototype created with MyEclipse for Spring

Another common scenario involves validating functional requirements while using web services.  Injecting scaffolding into the process involves two steps.  In the first, the business analyst or paired developer imports the WSDL to generate the back-end service and data objects.  In the next step, the business analyst or paired developer scaffold the web layer from the generated Java Beans that represent the web services domain objects.  Again, this light-weight approach takes minutes to create the functional prototype to be used to validate requirements.

Perhaps the best part of using MyEclipse for Spring to scaffold and validate functional requirements is that the scaffold can be re-used and extended in the build phase of the project.  In essence, the time invested during the conceptual phase to validate the functional requirements with scaffold prototypes is gained back from reduced build time required – and you have visually validated the functional requirements before starting the build phase of your software development life cycle.

Try it Yourself

MyEclipse for Spring is available for a free, 30-day trial.  Start creating your own functional prototypes by downloading from http://www.myeclipseide.com/module-htmlpages-display-pid-4.html.