In-Depth

December Response Time

• 12/01/1999

Ian Archbell’s article (August ESJ, page 36) on eCobol presents a good case for maximizing reuse of legacy code and data, but fails to justify the author’s recommended solution – extending COBOL to do the Web server transactions and browser GUI presentation. Three-tier business modeling points to the value of segregating business layer code, including legacy COBOL programs and data sources, and legacy mainframe data, from the user interface.

The author briefly mentions that there are solutions that merge the best of client/server tools and platforms with mainframe services, without trying to redesign COBOL and the mainframe to handle Web server transactions and the browser interface. Examples for connecting a rich GUI development and Web delivery platform, such as NT, to legacy COBOL and mainframe systems, include middleware, such as MSMQ, MQSeries, CORBA-to-COM, Attachmate Emissary, StarSQL, and my personal favorite, ComTI. ComTI allows a client/server programmer using any client/server language, to call a mainframe CICS or IMS program, without understanding a thing about COBOL or the mainframe. The only change on the mainframe end is to permit a call to the program.

These kinds of middleware solutions address the real need to take a sizable core of existing COBOL programming, eliminating the need to develop from scratch, while permitting some customization to give the interface and graphical look needed for e-business. The fallacy of trying to use COBOL and the mainframe as the foundation for Web services and client interface programming, is that it only addresses legacy requirements. Compared to using client/server platforms and languages for the middle-tier Web services, using COBOL and the mainframe is very expensive and restrictive.

Paul Noeldnerl’s response to my article in ESJ makes some good points. I would not disagree that the three-tier model requires good application partitioning for it to work effectively. I would also strongly agree with segregating user-interface programming from business logic programming.

In saying that e-COBOL has the capability to deliver CGI, ISAPI and NSAPI applications, I was not arguing for business logic to be intermingled with user interface code. If you were using another language you’d have to partition the code in a similar way.

In his note, Paul has focused on a particular product implementation using COMTI that he feels is effective with this architecture – and he may well be right in his particular case. Within Merant, we feel it is important to support not only the COM or COMTI approach, but also we need to deliver solutions that embrace a range of solutions that enable the customer to choose the most appropriate solution for them, and typically does involve third-party software.

In fact, there are two different approaches to the problem of reusing legacy data and processes. These approaches may be used separately or in conjunction with each other. In the first approach – "modernization," the mainframe applications are largely unchanged and a "thin veneer" of a user interface is applied to the existing application. In the second, "componentization," the business rules are extracted and the application is re-architected within a component framework which is likely to be COM- or EJB-based. This approach requires significantly more effort (and is, therefore, likely to be supporting strategic system change), but at least captures existing business rules.

There is a wide choice of technology that assists the first approach. In the second case, there is much less choice of program understanding tools.

My case for COBOL is that whatever approach and whatever technology that is being used to "glue" the application together, COBOL should be the prime choice for business logic components for all the traditional reasons, including the fact that that is what it was specifically designed for.

I do recognize that there is a wide choice of technology that can be used to deliver new enterprise Web applications. In choosing that technology, business value should be paramount. I do believe that the companies that will be most agile in developing e-business applications will be those who can take advantage, not only of the skills of their current programmers, but their knowledge of their business itself – that is likely to be the most valuable resource to reuse. And that’s why COBOL still has a big role to play.

So, do I think COBOL should be used in every case and for all parts of the application? No. Do I think it has a significant role to play in enterprise application development today and can it help maximize reuse in developing e-business applications? Resoundingly, yes!

***

Just wanted to add one additional item to Teri Blumenthal’s "E-Mail Facts of Life" (October ESJ Humor, page 88): Congress is not initiating a 5-cent per e-mail message. I received a message forwarded to "everyone you know that uses e-mail needs to know this." It had a congressional bill number, and even a sponsoring Congressman’s name. I did a quick search by the bill number, and the first link was to an Internet hoax Web site. There was no such bill number, and there is no Congressman by the name in the message.

Some people need to get a life.