 | Level: Intermediate Adam G. Neat (adam.neat@accenture.com), Executive Manager, Accenture LLC
13 Jun 2006 Service-Oriented Architecture (SOA) is becoming widely accepted, but there are gaps in the industry's approach, level of experience, and understanding of how to apply SOA to enterprise IT environments. Explore ways to stretch the return on IT investment of legacy platforms, such as mainframes, by using SOA-based technologies to expose critical business functions as business services.
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.
Aren't mainframes dead?
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.
Understanding the challenges
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.
Solving the challenges
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.
Drag-and-drop functionality
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.
Reaping the rewards
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.
Resources 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
Discuss
About the author | 
| | 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.
|
Rate this page
| |
