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.
Community comments
Unbelievable
by Eirik Maus,
Re: Unbelievable
by Fady Moussallam,
Just use CORBA
by Eric Newcomer,
Re: Just use CORBA
by Fady Moussallam,
Unbelievable
by Eirik Maus,
Your message is awaiting moderation. Thank you for participating in the discussion.
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,
Your message is awaiting moderation. Thank you for participating in the discussion.
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,
Your message is awaiting moderation. Thank you for participating in the discussion.
The software described here is available for free download.
What we describe is the reverse. Cobol initiates the call.
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.
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,
Your message is awaiting moderation. Thank you for participating in the discussion.
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.