Article: Mainframe Integration with JBoss ESB and LegStar

by Stefan Tilkov on Feb 16, 2009 |

In a new article, Fady Moussallam & Mark Little describe how the open source JBossESB has been used to integrate legacy COBOL CICS applications without necessarily having to rely on XML and Web Services stacks. The authors start by describing the problems of first generation, mainframe-centric, integration, before they outline what they perceive as the strengths of adopting an ESB approach for the purpose of mainframe integration.

After an architectural discussion of what they term "ESB-centric mainframe integration", they offer a step-by-step guide on how to implement this architecture using JBossESB and LegStar, an open source mainframe integration solution. This enables programs implemented in COBOL, running on the mainframe's z/OS, to communicate with ESB-hosted Java components through WebSphere MQ.

Check out the article for more information.

Related Editorial

Impact of Java EE Frameworks on the Structural Quality of Applications

From Killer Apps to App Killers: The Devastating Effect of Architecturally Complex Defects

Cluster-Wide Caching & Scaling for the Cloud - A Look Inside Resin 4.0

The Rise of the Composite API Platform, a ‘Best-of-Breed’ API Management Solution

Managing Virtual Environments: Going Beyond Traditional Monitoring Tools

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Community comments

Unbelievable by Eirik Maus Posted

Re: Unbelievable by Fady Moussallam Posted

Just use CORBA by Eric Newcomer Posted

Re: Just use CORBA by Fady Moussallam Posted

Unbelievable by Eirik Maus

It is hard to believe that you need all those layers and layers of expensive software in order to start a remote job controlled by a text-based interface. One could imagine that the simplest solution would be to log in and submit the string that starts the intended cobol program.

I find the following passage quite neat: "ESB-centric mainframe integration also benefits from the wealth of XML optimization techniques that are available today in the open world to reduce memory footprint, as well as CPU consumption of XML-related activities"

This only applies, however, if you wrap your communication in a quagmire of XML, buses, routing, XA datasources and all that stuff. My experience is that there is no footprint to reduce if you only pass the commands and data back and forth using 20 year old command and file transfer utilities. Also, the code and effort needed to generate commands strings and parse the responses is much less than the one needed to integrate all that stuff in a testable manner in you application. And without "all that stuff" between the local side and the remote side, it is actually possible to find and fix the bugs quite easily.

That doesn't sell any products, though.

Just use CORBA by Eric Newcomer

The IDL-COBOL and PL/I mappings work very well for mainframe integration, and many of the early adopters of SOA on mainframes used this approach. And of course now they are concerned they are not able to achieve the same levels of performance and stability with Web services and java EE as they did with CORBA. It may be the case that no one is investing much in new CORBA systems these days, but an article on mainframe integration, especially one that includes SOA, should include CORBA.

Re: Unbelievable by Fady Moussallam

layers of expensive software

The software described here is available for free download.

starts the intended cobol program

What we describe is the reverse. Cobol initiates the call.

quagmire of XML, buses, routing, XA datasources

Not really. There is no XML or XA involved at all in the scenario described. Also, if you observe the network traffic, it is hard to leave a smaller footprint.

the code and effort needed to generate commands strings and parse the responses...

Most bugs come precisely from parsing. Hibernate or JAXB have demonstrated the value of automated binding versus hand coding.

Re: Just use CORBA by Fady Moussallam

I like to picture ESB servers as general purpose transformation and communication servers. In a sense, CORBA ORBs, or the IBM CICS Transaction Gateway, are also transformation and communication servers.

The architecture we describe here attempts to make optimal use of the ESB capabilities. Turning COBOL to java is yet another transformation process so why not implement it as an ESB transformation action. Communicating with a mainframe requires managing the mainframe endpoint so why not use the ESB endpoint management capabilities.

Ultimately, the ESB becomes the single integration server to manage and deploy to.