Home > SOA News > SOA project links to mainframe batch systems
SOA News:
EMAIL THIS LICENSING & REPRINTS

SOA project links to mainframe batch systems

By Rich Seeley, News Writer
16 Jul 2007 | SearchWebServices.com

News on SOA, EAI, Web services
Digg This!    StumbleUpon Toolbar StumbleUpon    Bookmark with Delicious Del.icio.us    Add to Google

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 Architect, Pacific 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.



Sound Off! -   Be the first to post a message to Sound Off!


Tags: Service-oriented architecture (SOA) educationService-oriented architecture (SOA) developmentGrid computing and virtualization for SOAService-oriented architecture (SOA) orchestrationVIEW ALL TAGS

Digg This!    StumbleUpon Toolbar StumbleUpon    Bookmark with Delicious Del.icio.us    Add to Google


About Us  |  Contact Us  |  For Advertisers  |  For Business Partners  |  Site Index  |  RSS
SEARCH 
TechTarget provides enterprise IT professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective IT purchase decisions and managing their organizations' IT projects - with its network of technology-specific Web sites, events and magazines.

TechTarget Corporate Web Site  |  Media Kits  |  Reprints  |  Site Map




All Rights Reserved, Copyright 2001 - 2008, TechTarget | Read our Privacy Policy
  TechTarget - The IT Media ROI Experts