Morten Udnæs fra Miles deler sine erfaringer med programmering av høyvolumløsninger i Java mot fagsystemer skrevet i Cobol. Til tross for at de fleste nå programmerer i Java og Java brukt på riktig måte er i stand til å ta over fagsystemene skrevet i Cobol, så vil de Cobol-baserte systemene fortsatt opprettholdes i overskuelig fremtid og det er derfor viktig å få til en god sameksistens samtidig som høyvolumegenskapene bevares og om mulig forbedres.

Javazone er etter vår mening den viktige utviklerkonferansen i Norge, kanskje i Europa, og vi synes følgelig det er viktig å bidra både faglig og som sponsor på Javazone. Selv i disse finanskrisetider ligger konferansen an til å sprenge deltakergrensen samtidig som det høye faglige nivået opprettholdes.

Abstrakt om Morten sitt foredrag - "The forgotten art of batch programming":
This talk is about handling massive amounts of data from a file based legacy system. You may think this is a stupid example. Who would ever get 1.000.000.000 transactions in files? Orders will be placed from Web and properly load balanced as they get in. But the fact of the matter is, don't be so sure. There is a lot of legacy systems out there. In 1997 the Gartner Group estimated that there were 240 billion lines of Cobol code in active apps. Something like 90 percent of financial transactions are processed by Cobol code, and 75 percent of all business data processing is Cobol. Most of that code is still there after being fixed for 2000 bug.

So why is all this Cobol stuff relevant to me?
I develop using Java, not Cobol (Thank God!). It's relevant because Java is ready for the heavy lifting of replacing all this code. But since all systems can't be replaced in one go, you must interface with the existing solutions. Doing that using typical java stack in the typical java way, can give you an over-engineered and badly designed solution.
The speaker used 3,5 years as a software architect and developer replacing large mainframe applications using best practice Java architecture (message oriented, Spring, Hibernate etc). Doing so he realized that new techniques have their place, but processing large batch files using Hibernate probably wasn't the easiest way of dealing with legacy code and integration.
This talk is about what you do when your boss asks you to develop the mega-file-processing-foobar-application.