Wednesday, June 14, 2006

Batch Job Flow Design is equal to EDA

I have my roots in the old IBM370 JCL. What I like about EDA is that designing an EDA is very similar to designing batch job flows. Where you write a record to a file, you publish an event. Reading from a batch file is consuming from a topic. Where you read multiple files in balance, you come to complex event processing. Batch programs are decoupled. Programs write records and others read records, without any knowledge of each other's existence.

Simply said: Just take out the read/write-to-end-of-file loop from a batch program and the program is modernized to play its real-time role in an EDA.

Another way is to slice up batch files to messages and to queue up messages to batch-files; both at the perimeter of the ESB.

This is the way I explain the EDA-mindset to our analysts and programmers. And it works... (as far is they are old enough to know anything about batch programming ;-)).

1 comment:

Anonymous said...

hello.

I agree, however there are remarkable differences : (I am using the term extract = batch file)

- latency (extracts are generated 1 per day, moved to destination system and processed ; event messages are souring at the time when of business event occurred in source, flow via bus and they are processed at the end by some service = latency is in seconds

- format (extracts are flat files, charsets, special marks problems ; events on the bus are usually xml messages with xml schema definition.

- exactness (I ve seen 55 extract files generated in 1 midnight containing separate entities, difficult to manage ; event message ususally contains full,consistent change information or at least ids to be enriched later)

Roman

-