RSL COM has launched itself to MARS

One is Cobol, a legacy programming language used to develop applications for older hardware; the other is Java, one of the newest and possibly the most talked about language.

Unwilling to choose one over the other, RSL COM’s European cellular unit (formerly Motorola Telco) in Basingstoke, U.K., decided to take advantage of both languages.

The reseller of cellular phone air time was processing hundreds of thousands of invoices each month using the Motorola Billing System (MOBS), originally developed in 1994 using Cobol on Digital Equipment Corp.’s VAX platform. It handled cellular subscriber billing for the U.K., France and Germany while supporting different network providers in all three countries.

Knowing it faced a year 2000-compliance issue and looking at a mission-critical system sitting on a legacy platform with slow development turnaround, RSL COM decided it needed new technology.

After reviewing about 10 products, the Netron Distributed Systems Solution (DSS), which integrates Internet and multi-tier client/servers into existing systems, came out on top. So did the decision to adopt a Java/Cobol client/server strategy using RSL COM’s extranet as the interchange medium.

According to Abe McIntosh, RSL COM’s European Telco MIS manager, the choice was helped by the fact Netron’s DSS had already been used to build multi-tier client/server systems for the Web, and developers could reuse existing business rules.

According to Peter Ruttan, chief technology officer at Netron, reuse is important because recreating an entire system is a “mind-boggling” exercise.

“No one could really afford to do that,” he said. “Nobody is going to get board approval who says, ‘Hey, you know what? We need to rewrite all this stuff and we’ll be happy for the rest of our lives.’ It’s not going to happen, so we have to find an alternative way.”

RSL COM’s new system, currently in production in the U.K, is called MARS (Motorola Airtime Reseller System). Thin clients are now written in Java 1.1 on Windows NT-based PCs and fat servers are written in Cobol, using frame technology for both languages.

So what had to happen to make Java and Cobol work together?

According to McIntosh, using simple TCP/IP socket-based massaging, the company was able to initiate Java calls into the Cobol business servers and then retrieve or update information from within the database using embedded SQL in Cobol.

“This was facilitated by generating a simple piece of middleware to handle the client to server transactions,” he said.

According to Netron, Netron Frameworks use TCP/IP to link Java clients on remote workstations to Cobol servers. A Cobol router program determines which Cobol/Unix servers are needed and signals them to store and retrieve data from RSL COM’s 40GB of distributed Informix databases.

The only problem is that Java knows nothing about fixed-length strings and Cobol knows nothing about any other kind. The development team solved that problem by framing Java utility classes that package strings into various fixed-length formats – character, time, date, integer, decimal, etc. Once these classes were framed, Java and Cobol meshed together smoothly.

According to McIntosh, the retention of the Cobol business logic element was crucial in that any other option would have involved re-writing the proven and tested business logic in another 4GL.

“Given that the business had not fundamentally changed how it operated the code relating to the business rules could be simply extracted and re-used,” McIntosh said. “Java was chosen for the client presentation application due to its Web-enabled features. I also wished to future proof our application and ensure that it was able to run on all of our legacy client platforms” — PC, Xterminal, Mac, etc.

The main problem initially with the MARS implementation, he said, was around latency. The round trip from a Java client through middleware and a Cobol server to a database and back again was around 20 seconds.

“By working on improving the multi-threading and asynchronous event handling elements of the middleware and also by optimizing various Java elements we managed to reduce this to less than one quarter second in a production environment,” he said. “Also, we have seen a natural evolution and maturity associated with the JDK — resulting in faster and more efficient code.”

The benefit of this system, McIntosh said, is the overall application has increased in performance, modularity and scalability. “Maintenance is easier,” he said. “The Java front-end is more intuitive to the users.”

McIntosh offers this advice to other companies looking to the same sort of implementation: “IT is predominately about risk management. There is no set recipe for solving technical solutions. Rational decisions have to be made about when to develop from scratch and when to reuse.

“As with our case, you can mix these options as well. Sometimes software has a finite and short shelf life, and is not business critical – in these cases development of throw-away software is acceptable. Other times the software is business critical and there is normally no opportunity to undertake major developments from scratch – hence reuse the obvious and future proof the whole with the appropriate new technology wrappers.”