to homepage
 Weekly emails: how to advanced search
 Glossary lookup:


> opinion > vendor viewpoint

Web services ease mainframe integration

by Mike Gilbert
August 2nd, 2005

Skeptics claim that SOA is just another acronym for the same old promises of more flexibility and greater agility through re-use of technology components. Object Oriented (OO) architectures and then Component Based Development (CBD) promised levels of re-use but neither were applicable to legacy applications because of assumptions about technology and interface paradigms that did not fit. In addition, competing standards reduced the opportunity for reuse between diverse organizations, teams and packages. Service oriented architecture (SOA) does not presuppose an OO or CBD model, and applies equally to procedural programming and other paradigms for application construction. SOA offers technology-agnostic re-use.

• print  • comment

Smart IT organizations are achieving the transition to SOA in several evolutionary steps, selecting the most suitable candidate legacy applications first.

Mike Gilbert is director of product strategy at Micro Focus, a leading provider of mainframe and COBOL development and migration tools. It offers a range of products to reuse legacy applications with contemporary architectures and web services.

Glossary terms: legacy, SOA, web services, composite application, development, lookup tool

The appeal of SOA is that it embodies good practice, but it does not set out to standardize to a level sufficient for implementation. SOA is a concept not a technology, and allows the concept to be applied regardless of middleware. SOA is useful to formalize the conceptual bridge between legacy and contemporary technologies like J2EE and .NET. There is almost universal agreement that SOA is a good model for application composition and re-use and this is leading to adoption in many forward-looking organizations.

SOA goes hand-in-hand with one of the fastest growing technologies from the last couple of years: web services. Web services provide a platform and vendor-neutral set of standards and implementations suitable to execute composite applications based on the SOA model of construction. Web services are standards for implementing both 'service' invocations across technology boundaries, and for transmitting documents regardless of end-point formats. Adoption continues to be slow in most organizations. This is largely due to slow standardization and delivery of the necessary infrastructure to provide the quality of service required for business-critical applications.

Service-enabling the core
How can SOA enable integration of core legacy services with future development platforms?

This is essentially a two-stage process. First, the legacy applications must be converted into re-usable core business services. This means peeling away the original operator interface from the underlying 'services' in the applications that perform useful business functions. These core services are redeployed to their host platform in such a way that they can be invoked though some well chosen SOA-based middleware (for example web services). SOA does not presuppose any processing paradigm or data formats. Legacy applications use a wide variety of both, and connections may be made through customized 'adapters' or third party tools. Also, SOA allows the construction of business-level entities, and is not constrained by existing technology boundaries — such as OnLine Transaction Processing (OLTP) units of work, job steps etc. These are physical boundaries that often bear no relationship to anything reusable in a business context.

Second, these services are 'published' to the development teams building new client offerings, such as real time transaction systems, business reporting and approval processes, all using established international standards of communication. Published services appear as lists of fully production-hardened entities such as web services, Enterprise Java Beans (EJBs) or similar within the new development platform.

Smart IT organizations are achieving the transition in several evolutionary steps, selecting the most suitable candidate legacy applications first for conversion into core services to enable key development initiatives.

Points to consider
There are some important technology considerations to bear in mind.

An SOA must respect the 'statefulness' of the services that are invoked. Legacy applications are constructed with assumptions about how long transient data storage survives and how different 'instances' are identified. The simplest and most effective model is one where each interaction is indivisible and independent of any other. This is the model adopted by many OLTP systems on legacy platforms and thus supports straightforward conversion.

In general, core services should encapsulate single query or update transactions (indivisible units of work) to provide a sound basis for recovery in the event of service failures. Where a service is composed of several transactions, care is required to select sequences that cannot leave the underlying data in an inconsistent state.

It is sometimes thought necessary to extend transactions across the SOA-legacy divide. This approach contains dangers and difficulties in ensuring that the different platforms can guarantee safety and performance. Until web services matures to the point where these provide a full service capability including infrastructure and management, many tasks (like service journaling and recovery) must be handled through complex system programming techniques which require deep platform-specific understanding.

The SOA model has not defined whether transactions should flow across service boundaries. There are good arguments to suggest that they should, (to provide integrity) and arguments to suggest they should not (to provide isolation). The whole industry needs guidance and standards on this issue. Application designers must know when they are constructing tightly coupled or loosely coupled services, since the design constraints are quite different. The decision should take account of the organizational (physical as well as commercial) boundaries between interacting parties, since internal integration projects may allow different principles to be employed from true B2B interactions.

In summary, any industry sector competes and maintains profitability by consistently streamlining to reduce costs, modernizing with agility, while preserving industry expertise and the need to avoid unnecessary risks. It makes business sense for an industry that recognizes the importance of exploiting competitive advantage through technology to consider an approach that allows participants to identify, upgrade and re-use existing legacy assets, while also taking advantage of new technologies. A move to SOA and web services offers organizations the option to do this.

More on this topic


Service reuse unlocks hidden value
By linking up existing functions to create new, composite applications ...

More legacy gain than pain with SOA
Using web services for legacy integration means confronting an inevitable culture clash ...

The CIO's dilemma
Applications the IT group has written are unique to that organization ...


Copyright © 2002-2006, Procullux Media Ltd. All Rights Reserved.