News Stay informed about the latest enterprise technology news and product updates.

SOA project links to mainframe batch systems

SOA systems can include legacy mainframe batch processing systems, at least until the ancient software and hardware can be scrapped, according to the architect for Pacific Blue Cross.

What happens when new service-oriented architecture (SOA) applications from 2007 meet state-of-the-art mainframe batch-update systems from circa 1977?

I have not polluted my new systems, but I've allowed the participation of the two systems in a SOA environment.
Bruce Hogg
Enterprise ArchitectPacific Blue Cross

Legacy batch systems can be made to work in an SOA environment, says Bruce Hogg, enterprise architect for Pacific Blue Cross, which is part of Blue Cross Life Insurance Company of Canada, and is British Columbia's largest provider of extended health and dental benefits. He has spent the past 18 months finding ways to make batch processing systems work in an SOA enterprise system where users generally expect near real-time responses.

It is not particularly easy and it is not a permanent resolution. Over the next five years, Hogg plans to replace the legacy systems, but while batch processing does not have a future in his SOA environment, linking them into it is currently a necessity because SOA is here today and the mainframes won't be gone for several years of tomorrows.

The transition from legacy to new systems will take from three to five years. There are approximately 50 systems that will need to be either altered or replaced.

"It's a massive undertaking," Hogg said.

One of the strategies being marketed to enterprise architects in Hogg's position is the so-called "lipstick on the pig" solution where the legacy systems are updated to look as if they were more modern. He chose not to go in that direction. After assessing the situation, he said it was clear that the legacy batch systems would never be the ideal fit for an SOA environment.

"After doing do diligence we decided the replacement of the systems is probably better because of the limitations of the systems," he said.

But he needed an interim plan that would allow the existing legacy systems to participate in the SOA environment for as long as five years until they can be replaced.

After selecting the Sonic enterprise service bus (ESB) from Progress Software Corp. he also decided to implement what Progress is calling the "leave and layer" approach. In this SOA strategy, legacy applications continue to provide required data to the new services-based applications until the old technology can be replaced.

As Hogg explains it, "When we brought in the ESB and the service-oriented concepts we started to build new SOA-compliant applications and SOA services. We started to look at new systems that were SOA compliant, but at the same time I need to expose those legacy systems using an SOA model."

Besides the Sonic ESB and SOA orchestration tools, Hogg used iWay adapters from Information Builders Inc. to connect to those legacy systems.

"We've got a CICS adapter," he explained. "We've got a number of other data adapters. So we've opened up in a limited fashion the backend systems to participate in a legacy-strategic systems relationship."

In architecting the inclusion of the legacy systems into his SOA environment, Hogg wanted to be sure the legacy didn't "pollute" the new applications.

"Our new systems know nothing about the internals of those legacy systems," he said. "We've abstracted them using a common message format. Basically that's a meta model that sits in the middle of our SOA."

As an example, he said, "If a new strategic system needs to enroll a new member, all it knows is it's creating an XML document using standard specific Blue Cross format." The service bus passes that through a number of other services that translate that into a mainframe batch file format with which the legacy system can work.

For more information
SOA in a box?

Progress builds alternative SOA stack with Actional buy

"I have not polluted my new systems," Hogg said, "but I've allowed the participation of the two systems in a SOA environment."

Having decided not to put lipstick on the pig, the batch processing systems do not respond in anything like real-time. When data is needed from a flat file in a legacy system, end users working with a portal to the SOA applications receive a message telling them to check back later. "Later," of course is the x number of hours until the next batch update runs on the COBOL mainframe systems.

But Hogg said users have been understanding that it may take time to process a request for legacy data, which might include information about which Pacific Blue Cross members are enrolled in which insurance programs. As SOA applications replace batch processing, this patience stands to be rewarded.

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.