Service-Oriented Architecture (SOA) is one of those technologies that has been lying quiet and untapped for more than 20 years. But since the advent and subsequent adoption of Web services, SOA has been given a new lease on life. SOA is the wave of the future when it comes to development architectures. Its model of exposing data and information as a service (or services) makes SOA a powerful concept and a complete shift from the current application-building-block paradigm. When coupled with the much-heralded model of ubiquitous or utility computing, where processing capacity is added and removed in the same way one adds or removes batteries from a flashlight, SOA has awesome potential for large-scale enterprise computing.
One area in which SOA is only just beginning to gain popularity is in increasing the lifespan of legacy applications. This article shows the ways in which SOA can help extend your ability to reap a greater return on investment (ROI) from legacy and mainframe applications. The mainframe is a proven technology, and in this article, you explore ways in which information technology (IT) organizations can continue to leverage mainframe investments by SOA-enabling those mainframe applications to extend their life.
Evolving toward a service-oriented world
The basic concept of SOA is that it encapsulates an enterprise or organization within a construct of services, where everything from data to logic and business functions becomes some type of service.
For example, you could have a service that exposes functionality in this way: When you pass in a postal code, the service returns the associated suburb name. Although there's nothing especially complicated about this one, more complex services can involve multiple back-end data sources, business processes, and so forth.
The glue in the middle of these transactions is predominately Web services, typically using Simple Object Access Protocol (SOAP) over Hypertext Transfer Protocol (HTTP). I use the word "predominately," because there are other ways to connect to an SOA bus using technologies such as IBM WebSphere® MQ.
Most enterprise-sized organizations have mainframes. They're either lurking around in data centers or still performing core, business-critical functions. And it's not uncommon to find the fundamental technologies that operate within these mainframes to be more than 15 years old.
COBOL is one such beast that's still very much a part of day-to-day operations within enterprise mainframe environments. In fact, Gartner Group stated in 1999 that more than 200 billion lines of COBOL code are still in existence. The latest information from Gartner indicates that COBOL business applications have not been reduced since. Bill Ulrich, President of TSG Inc., states that 5 million new lines of COBOL code are written each year, and IBM's mainframe group is selling more kits now compared with 15 years ago. Clearly, the mainframe isn't dead. With so much investment in mainframe and legacy systems during the past 20 to 25 years, it doesn't necessarily make sense to throw it all away only to replace it with more commodity platforms.
The challenge that IT organizations are facing in the mainframe arena is complex and multifaceted. First, many of the applications operating on these legacy platforms were written many years ago, and the original developers have long since moved on. Second, the applications are typically so complex and critical that many organizations are understandably nervous about decommissioning or porting them to mid-range platforms.
This challenge is a critical one. It can lead to disparity in an IT organization when new applications and functionality are added not to the core mainframe but instead to other platform architectures; for example, Microsoft® .NET® or Java™ 2 Platform, Enterprise Edition (J2EE)- and Java Platform, Enterprise Edition (Java EE)-based platforms. Such designs often require that complex interoperability mechanisms be in place to tie the mainframe to mid-range platform and cause a structured enterprise architecture to become splintered and blistered.
Next, there's the challenge around the Internet-driven computing model, whereby Internet sites and portals require access to data stored on back-end systems. The problem here is that connecting those back-end and legacy systems to the Internet directly isn't good practice. Mainframes (and the applications within them) were designed to process long-duration tasks and typically support concurrent user loads in the hundreds or low thousands. They weren't designed to handle tens, hundreds, or even millions of users and requests, all simultaneous and in real time.
Over the next few years, as the industry gains SOA momentum, IT architects will start to purchase business workflow bundles rather than application packages. They will then deploy these business-workflow bundles as part of a conglomeration of existing business services that will be wired into an Enterprise Services Bus (ESB) and integrated with constituent applications. With this in mind, how does an IT architect use a service-oriented approach to help resolve the challenges?
First, you must conceptualize the applications on the mainframe (or legacy environments) not as applications but rather as a "bucket" of services. You must mentally decouple the application from the underlying platform architecture (in this case, the mainframe). SOA inverts the concept of an application such that applications are simply a logical grouping of capabilities accessed through service interfaces. This article focuses on ways to continue receiving a positive return on investment (ROI) from your mainframe platform, so let's explore solutions to the key challenges facing IT organization outlined earlier.
SOA strategies for the mainframe
You can use SOA as a wrapper around the mainframe application in such a way that those legacy applications become part of an ESB. It would be utopia for architects to have a catalog of enterprise services available in a ubiquitous manner so that as new applications and business capability development programs commence, it's simply a matter of bolting the new application into the ESB, then reusing those services that were exposed.
If it sounds straightforward, that's because it is. If you considered the conceptual mainframe discussed throughout this article being one of IBM lineage (for example, an IBM OS/390® or zSeries® computer), you can rest easy. IBM offers a raft of developer-side tools and workbenches through which SOA architects and designers can connect to legacy services through drag-and-drop and point-and-click modeling.
For example, IBM products such as WebSphere Studio Enterprise Developer allow developers or designers to canvas their applications by dragging in the services that are exposed from a legacy mainframe environment. The run-time view of this canvassing would have a services bus construct (that is, the ESB) providing the bus itself, brokerage, and a messaging layer in the middle.
Further, by using a mixture of IBM technologies such as IBM WebSphere Host Access Transformation Services (HATS), SOAP for Customer Information Control System (CICS®), or even WebSphere Information Integrator, the mainframe's application adaptors and interfaces can be exposed to anything that's also bolted into a common ESB (even Microsoft .NET applications).
In this manner, the new application you're developing simply calls the services that exist, and a Java developer doesn't need to know that the services he or she is requesting reside on a mainframe platform. It's completely transparent. I'm glossing over some of the details, but make no mistake -- If you consider the complexities, costs, and status of a mainframe, using these tools to give legacy applications a new lease on life is fairly straightforward.
You may have already experienced the drag-and-drop features of Integrated Development Environments (IDEs), such as IBM Rational® Application Developer for WebSphere Software. If so, you probably noticed the ease with which a developer (or business analyst) can build up the fundamentals of an application by dragging components around the IDE.
With this in mind, for an SOA-enabled environment, the same concept applies. You can drag -- from a catalog or service lists -- the appropriate service, and then bolt that service into the rest of your application flow. Then, either through hand-coding or by using the WYSIWYG capabilities of the IDE tool, you can put those services into a workflow that you've dragged in from the catalog listing, and tie them into an end-to-end business process.
Example: Internet-facing portal application
Imagine for a moment that you have an Internet-facing portal application that allows customers to order beauty products. Through the portal application, customers can select products from a catalog and then place the actual order. (See Figure 1.)
Figure 1. Example portal application using services from a mainframe
The order module of the application obtains customer details from the mainframe. However, because of some mythical legacy configuration or design flaw of the mainframe-based COBOL application, the mainframe only stores postal codes, not suburbs. Through your enterprise developer IDEs, you can create the portal application's Customer Suburb field by dragging in a service from the ESB service repository and creating a process that, when the customer details are retrieved, use the Postal Code field as an input parameter to the IBM eServer® pSeries™ mid-range application that hosted the postal code-to-suburb lookup service. Because the postal code-to-suburb lookup service is on the same ESB as the exposed mainframe application's services, grouping all these services together to form single a process is child's play.
However, the flaw in this simple example is the probability that the Internet-facing portal application is extremely popular and may have tens of thousands of concurrent users online at any time. Why is this a problem? The key concern here in using services that are exposed off the mainframe is with the load differential of Internet-deployed applications and how that load differential affects the mainframe.
As I noted earlier, mainframes aren't designed for or accustomed to high volumes of real-time user requests. Having real-time online requests on the order of 20,000 to 50,000 per second would break a typical mainframe environment. However, by encapsulating a mainframe environment within an SOA layer, you could use some of the caching and read ahead-type features that ESBs such as WebSphere Process Server provide, thus insulating the mainframe. Figure 2 highlights the way this setup looks in a typical environment.
Figure 2. Using ESB caching to extend the scalability of the mainframe
The strategy: Cache data through the ESB
The strategy works like this: You can make certain data, either static or that which changes infrequently, persistent or cacheable through the ESB. SOA-enabled applications (for example, portals) that are wired into the ESB services layer can then transact with desirable performance without bringing down the heavy iron mainframe back end.
Consider, for example, a customer records database that resides on the mainframe. In theory, this database could be cached in the ESB layer so that frequently or commonly accessed information or data doesn't need to be sourced directly from the mainframe application each time. You can control the synchronization either through a push-update mechanism (when updated in the mainframe application, the changed details are pushed up to the ESB layer) or by setting the cache to expire after a defined period.
Alternatively, you could design the portal-based application (and subsequent service workflows created)
so that when a customer first logs into the portal, that customer's information is retrieved through the mainframe
application's exposed services in an asynchronous background request (a pre-fetch), then stored in a
cache on the ESB for the duration of the user session. This setup reduces the real-time request load on
the mainframe.
The real benefit of this kind of design is exposing legacy business functionality that resides on a mainframe in such a way that it allows application architects and designers to reuse working application functionality rather than having to develop it from scratch. The cost savings are enormous, and the time-to-market for new applications or functionality is greatly improved. Consider the implications for banking and financial-based institutions, all of which have colossal mainframe environments that run their core business. Decommissioning those mainframes and replacing them with new and ported applications is an incredibly costly and risky undertaking.
You might ask that by going down the path of SOA-wrapping and encapsulating legacy applications, aren't we simply delaying the inevitable? Won't we still have to port the applications in the future? I say both yes and no. Yes, you are delaying change, but you're managing that change in a more structured manner. Of course, over time, the mainframe applications will need to be ported, but by SOA-enabling these mainframe applications, you provide an inherent fabric that maps out the core service functionality to implement in a future porting or redevelopment exercise.
Remember, the risk and cost of porting a mainframe application is not limited just to the
ported application. External and interfacing applications require modifications and regression testing, too. However,
by SOA-enabling the applications on the mainframe, you can help reduce the future cost and impact of the porting,
because any interfacing application cares only about the services it accesses. For example, you won't need to change the
postal code-to-suburb application example if the service contract on the ESB still passes in an input
parameter of postalcode and accepts a string with the suburb name. As long as
that service contract doesn't change, your application acts in the same manner as before.
So, mainframes are not dead. IT organizations don't need to introduce additional risk, complexity, and costs into their IT programs by porting legacy applications. By implementing a service-oriented-based approach, IT organizations can continue receiving a return on mainframe investments while at the same time elegantly evolving their enterprise applications toward a pure-SOA model. Not only this, organizations will reap other benefits such as being able to increase their platforms’ availability, performance, and accessibility and interoperability factors with the proper implementation of an enterprisewide service-oriented architecture. In this way, when it's time to perform the real port, the cross-application impact is negligible because everything in the enterprise is service oriented rather than application oriented.
Learn
-
The presentation from the IBM Software Group,
"WebSphere Developer for zSeries," discusses
zSeries interoperability; for example, SOAP on CICS, WebSphere MQ, and WebSphere HATS.
-
Read about integration and on demand business:
The Mainstream, (Issue 9; 2004) the IBM eServer zSeries and OS/390 software newsletter.
-
Get more information about
WebSphere MQ.
-
Read about the role of Web services in SOA:
"Service-Oriented Architecture expands the vision of Web services, Part 1: Characteristics of Service-Oriented Architecture," (developerWorks, April 2004) by Mark Colan.
-
Read about the value and approach to migrating to an SOA in
"Migrating to a service-oriented
architecture, Part 1: Introduction and overview," (developerWorks, December 2003) by Kishore Channabasavaiah, Kerrie Holley, and Edward Tuggle, Jr.
-
The series continues in "
Migrating to a service-oriented architecture, Part 2: Introduction and overview continued," by Kishore
Channabasavaiah, Kerrie Holley, and Edward Tuggle, Jr. (developerWorks, December 2003).
-
Visit the
developerWorks Web services zone to expand
your Web services skills.
-
Stay current with
developerWorks technical events and webcasts.
- Search for related books at Safari Bookshelf.
Get products and technologies
-
Download a free trial version of
WebSphere Application Server Version 6.0.
-
Build your next development project with
IBM trial
software, available for download directly from developerWorks.
Discuss
-
Participate in developerWorks blogs and get involved
in the developerWorks community.
Based in Melbourne, Australia, Adam Neat is an executive manager with the management and IT consultancy firm, Accenture. Adam is the head of the Custom Solution Architecture practice for Asia-Pacific, as well as the head of the Innovation and Architecture practice for Australia. Adam holds several industry certifications in various platform technologies from organizations, is a published author and writer, and is an Associate Fellow of the Australian Institute of Management. You can reach Adam at adam.neat@accenture.com.
Comments (Undergoing maintenance)
Table of contents
Next steps from IBM
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
