An Approach to Identify and Extract SOA Services from Legacy iSeries

Applications
***Rama Krishna Thommandra, **Hari Prasad Chinta, *Nakul Sharma, *Sateesh Ranjan

***Senior Project Manager, **Senior Software Engineer, *Software Engineers (HCL

TECHNOLOGIES Ltd)-Email {ramakrishnaTM, hariprasad.chinta, nakul_sharma,
sateesh.ranjan}@hcl.in

Abstract enterprise. This value of the legacy systems arises

because these systems encapsulate substantial knowledge
Making legacy applications work in SOA architecture is a of the business and significant business functionality in
definite boon to the enterprise. However before embarking the language and tools that current staff understands.
on SOA-enablement, a very important question that needs
to be answered is: Where should we look - within the However, these legacy systems are also the cause of pain
legacy applications - when searching for services that can points as listed in Figure 1.
be re-used? Though there is a lot of information available
on what SOA is and how legacy can benefit from SOA, Figure 1: Pain Points of Legacy systems
there has not been a generic approach specified on
EXACTLY WHERE in the legacy applications one can look • Application Deficiencies
when attempting to extract services. The paper is a listing
of all the legacy application artifacts that need to be o Undocumented Application
considered while extracting services from monolithic o Tightly-coupled Modules
legacy applications. o Monolithic non-modular architecture
o Lack of a consistent underlying architecture
Goal and Scope of the Paper (Redundant code, functionality and data)
o Closed and outdated technology that is difficult
This paper attempts to list some of the signposts in to integrate and interface with new, open
existing legacy applications that can be used to identify technologies and modern distributed
and extract services from such systems so as to render the architectures.
monolithic legacy application into multiple useful o UI limitations (Inefficient re-entry, navigation,
Business Services. etc.)

This paper addresses this goal solely from the perspective • Side-Effects of Operating Legacy Applications
of functions typically found in a business application.
o High cost of ownership
o Low Agility
1. Introduction o Knowledge of these systems is usually restricted
to a core set of people who are difficult to
Overview of Legacy Systems replace
o Limited and difficult integration of functionality
Most modern analysis tends to classify applications as o Limited workflow support
"Legacy" depending on their age – say, typically, twenty- o Difficult to exploit new technologies
odd years – and/or usage of a relatively old platform, o Single-platform limitations and risk
language or technology. Typically, these are applications
and data that have been inherited from languages, • Changing Realities
platforms, and techniques earlier than current technology.
However, even today these legacy investments are o Shrinking talent pool of developers skilled in
running critical business processes. In fact, Legacy legacy systems and decreasing vendor support.
systems are often considered to be a "cash cow" for the o Difficultly training new end users and developers
Of all the points mentioned above, the biggest difficulty is o Providing interoperability with more modern
making Legacy systems interface with new, open Web-based systems (This would extend the
technologies and modern distributed architectures. practical life of legacy routines and processes)
o Lowering the overall IT cost structure by sharing
Overview of Service Oriented Architecture business services across multiple applications
o Decreasing complexity by greatly reducing
redundancy in the enterprise
In today’s world, this new, open and distributed
architecture is best exemplified by Service Oriented
• SOA benefits to the Business
Architecture (SOA). Undoubtedly it is possible to re-use
legacy assets in a more agile alternative without using
o Improving productivity, agility, and speed
services or without using SOA, but our proposition is that
o Closer alignment of IT with business allows for
by making them as services on a SOA architecture we can
greater agility in modifying business processes
create more flexibility for utilization of such services
from unexpected quarters in the future, in effect creating a
more agile application which, in turn, would facilitate the SOA characteristics that enable or facilitate the above
creation of an agile enterprise. mentioned advantages are listed in Figure 3.

A detailed exposition on the various facets of SOA is Figure 3: Chief Characteristics of SOA
beyond the scope of this article. However, we feel a recap
of the same serves the purpose of setting the stage for • Abstract: Hiding the business logic from the service
what to keep in mind when exploring legacy applications consumers.
for probable services. With that intention we provide • Autonomous: If a service is autonomous it has the
below a very brief outline about SOA. basic data, or information to completely govern the
business logic that it encapsulates.
SOA separates functions into distinct units (services), • Composable: Services should be defined in such a
which can be distributed over a network and can be manner that it should be possible to facilitate the
combined and reused to create business applications. assembly of composite services resulting in higher-
OASIS (organization) defines service as "a mechanism to grained services.
enable access to one or more capabilities, where the • Contractual: Contract-driven agreement on service
access is provided using a prescribed interface and is descriptions serve to formalize obligations to be met
exercised consistent with constraints and policies as by the publisher as well as the consumer of the
specified by the service description." The commonly service.
agreed aspects of the definition of a service in SOA are: • Discoverable: It should be possible to ‘discover’ (or
search for) services across the network.
• Services are defined by explicit, implementation- • Loosely coupled: This minimizes dependencies
independent interfaces between services.
• Services are loosely bound and invoked through • Reusable: Define the business logic as reusable
communication protocols that stress location services.
transparency and interoperability • Stateless: Minimize retained information specific to
• Services encapsulate reusable business function. an activity so that any invocation of the service does
• Services may exist on different levels and provide not need to ‘remember’ data from earlier invocations.
different granularity.
Web Services is just one method by which SOA
SOA strategy brings enormous benefits to the enterprise architecture can be implemented. Web services are based
such as listed in Figure 2. on invocation using SOAP messages which are described
using WSDL over a standard protocol such as HTTP.
Figure 2: Benefits of SOA
Linking Legacy and the new, open technologies
• SOA benefits to IT and modern distributed architectures.

o Improving productivity, agility, and speed If we need to build more agility into Legacy applications
o Composing new applications from existing deploying services in SOA architecture is a good
software assets approach to adopt. SOA accelerates time to value in
o Align IT more closely with business legacy applications by:
• Decreasing complexity by providing a uniform way not intended to be a comprehensive exposition on
of linking services and a uniform framework for SOA and does not attempt to address the myriad of
integrating them. topics that SOA-enablement involves, e.g.
• Replacing static linkage of services with dynamic Governance, Performance, Security, Testing, etc.
linkage and reducing the resistance to change,
allowing IT to track changes in business processes. 2. Extracting Services from Legacy
• Providing an environment for reuse and encouraging Applications
consistency.
• Simplifying operations by providing a uniform way Note: Instead of simply listing down what legacy
to monitor and manage services. artifacts can be reviewed for mining of services, the
• Simplifying service implementations by handling approach adopted by this paper is to provide a brief
resources and other management tasks in service explanation of the preparatory work that must
containers. necessarily happen BEFORE service mining can
actually begin. This introductory material is covered –
However, based on the application deficiencies mentioned though briefly – in the sub-section A below. Sub-
earlier in Figure 1, it is not really easy to make the sections B through D concentrate on the IT artifacts
unchanged legacy applications effectively participate in that can be reviewed for mining of services.
SOA architecture. The critical pre-requisite that would
enable this participation would be the identification and A. CREATE A BLUEPRINT FOR A SOA-
extraction of possible candidates of services that can be
ENABLED ENTERPRISE
made available to a SOA-enabled ecology (i.e.
enterprise’s business processes, enterprise’s IT
infrastructure, vendors, customers, etc). Before we embark on a journey to identify and extract
services from legacy applications, we need to have a
clear definition of the business landscape (TO-BE) in
The fundamental problem that we are attempting to
which the SOA-based IT assets and business processes
resolve in this paper is to define a generic approach for
would function. This might –just, MIGHT – be the
identifying and extracting services from legacy
same as the current business landscape (AS-IS), but still
application keeping in mind the following criteria –
that decision needs to come out of conscious
deliberations. As an example, SOA can start in a small
1. The identified service should make use of code manner – say with web services – before growing into a
from legacy application – either unchanged or full-blown enterprise-wide architecture. In either case,
modified to eliminate the user-interactions it helps to have the AS-IS and TO-BE clearly defined
2. The process of identification of services should before we embark on identifying and extracting
encompass not only the legacy application but also services.
the manual processes that might accompany the
legacy work-flow or process-flow
1. Identify business domains within the enterprise
3. Depending on the nature of the service, it should be
business structure
re-usable either within the organization or from
outside the organization
Enterprises are typically composed of many business
function (for example, Sales, Marketing, Account
With the above-mentioned guiding principles,
Management, Customer Services, and so on) or
implementations (such as Mainframes and Wintel
• In Part II of this paper we attempt to lay down servers). Making sense of the big-picture in such an
guidelines on how to go about looking for and enterprise is facilitated by dividing the each facet of the
extracting services from Legacy applications. Part II enterprise – be it business function or implementation –
provides a listing of some signposts in existing into domains. Essentially, a domain would contain
legacy applications that can be used to identify and applications and functions that are connected tighter,
extract services from such systems. This topic forms and would therefore have greater dependencies to each
the main thrust of this paper. other than to the rest of the enterprise. This domain-
identification process would facilitate later processes
• In Part III of this paper we also document a very because of the advantages brought about by separation
simplistic approach to deploying a service extracted of concerns.
from legacy into a SOA architecture using Web
Services. However, please note that this last part is Use the following to identify business domains –
 • AS-IS enterprise organization structures • Identify the major and minor processes executed by
• TO-BE enterprise organization structures (if any TO-BE department in the organization structure.
change is being envisaged) • The domain should be validated for :
• AS-IS Menu Structure • Sufficiency of processes for executing the business
• AS-IS Business Functions • Have adequate “inflow” of data / information
• Those portions of Vendor’s systems that the AS-IS required to execute the processes
and/or TO-BE environments would interface with • Provide appropriate “outflow” of data / information
• Those portions of Customer’s systems that the AS- expected from the domain
IS and/or TO-BE environments would interface with
B. TOP-DOWN SERVICE MODIFICATION
Initial separation into domains may also be purely
conceptual, allowing for identification of application Figure 3 elaborates SOA characteristics. It would
functions that need to be exposed as services to the rest be advantageous to bear those characteristics in
of the enterprise. Once services are identified, domains mind while mining for candidate services (i.e.
need to be separated from each other by establishing functions that can be used to create services) from
clear boundaries enforced through use of gateways and within the legacy application.
firewalls. Such separation allows for better control over
application interactions and further flexibility for • The service should present the functionality to the
making changes to applications without dramatically user / consumer at the level of granularity that the
affecting the rest of the enterprise. user / consumer needs or understands.

2. Create a high-level Architectural Layout of how the • There are different kinds of re-usability ex. code
domains interface with each other re-use or functionality service. The key criteria to
be kept in mind when mining for services within
Use the following to define the interfaces between the legacy application is that one should mine for
business domains identified in earlier step - re-usable services rather than only re-usable code
snippets.
• AS-IS information flow between domains
• TO-BE interactions between the various domains – • SOA Services are typically published so as to be
functional and/or technical discoverable by others – from within the
organization or even from outside the organization.
When analyzing legacy functions that could
3. For each domain identified above, also identify possibly be converted into services, one should
business processes that make up the business keep in mind the users or callers of that service.
domain. That in turn should determine the kind of visibility
(i.e. publishing) that needs to be provided for the
Processes can be seen as the blueprint for the behavior service.
of people within an enterprise. All important activities
will be covered by a process, requiring the definition of • Levels of Abstraction that can be achieved within
ownership, relation with other processes et cetera. From a legacy function should be kept in mind. The
an IT perspective, when thinking about business legacy function that is being evaluated for its
processes related to a domain, you must also ask candidature as a service needs to be analyzed if it
can be abstracted, generalized or extensible. If not,
• What functions are contained within them the legacy function is, quite possible, very
• What data is used specialized or specific – and hence may not be an
• Where the data resides appropriate candidate as a SOA service.
• Who's using these processes (people or
applications) • Another related factor that can be analyzed is
whether it would be possible to build a formal
This can be a difficult task based on the design of your contract around that service wherein the publisher
in-house applications. as well as the consumer has certain obligations.

Use the following steps to identify business processes

that are a part of the identified domain
• When identifying candidate services, one should which of those are data that can be re-used
also bear in mind that the service should be self- by different user communities – some
contained (i.e. autonomous, loosely coupled, within the enterprise and, maybe, some
composable and stateless). In other words the outside the enterprise.
legacy functionality that is being converted to a
• Transaction Processes – Transaction
service should be
processes in legacy applications – ex.
‘Place Order’, ‘Make Reservation’, etc –
o Capable of having access to all the rule sets and are the backbone of the business. One can
data sets that can govern the service’s behavior review the transactions in the AS-IS and
o Definable in terms of data that it has access to – TO-BE designs to define which of those
without having to remember data pertinent to are re-usable enough – either today or
earlier runs. probably in the future – to qualify being
o Usable by the consumer without requiring abstracted into a service that is callable
detailed knowledge of the service before either from within or outside the enterprise.
invoking it
o Definable at the right level of granularity (When • Audit Log Process – Changes made to
mining for services, one needs to bear in mind sensitive data is many times auditable.
that there can be different levels of granularity of When reviewing the transactions we need
services. Rather than making one big (very high- to keep note of those that record such
grained service) it would be best to identify changes in an audit log. It is possible that
candidate services at a lower-level that can be we might be required to derive services for
composed into higher-grained service. In this query and presentation of audit logs.
attempt one should bear in mind that whatever be
• Processes that send data to systems other
the level of granularity at which a particular
than the legacy platform – The interfaces
service exists, the candidate service should
between the enterprise, its’ customers and
represent one complete function to its consumer.)
vendors are good candidates for extracting
services because these services can then be
With the above considerations in mind, the rest of the
made available on the internet. (ex. EDI)
paper identifies some possible sources from where
candidate services could be extracted from legacy • Archival of information – Periodicity of
application. Archives can have a constraint on the data
that can be available to services. It is
For each Business Process within the Domain perform definitely advisable to keep in mind the
the following steps. archival cycles when visualizing services.
o Identify “Information Publisher” processes
i. Map the business process with supporting
processes in the existing system Processes which are responsible for supplying
users with the latest information are also
o Identify “Information Generator” processes candidates for services because once these are
such as : made available as services and brought out of the
constraints of legacy technology, we can
• Application Set-up Processes - An example immediately consider many of such services for
where this information can be useful is the propagating critical information to various
User Profiles that get set-up for devices such as handhelds, tablet computers,
applications. Based on the profiles, a broad internet, charting tools, etc thereby at least
categorization of user community can be facilitating the creation of a more agile enterprise
done which in turn will have usage in responsive to changing business dynamics. Some
defining the kind of services that each user of the processes that can be reviewed from this
class would be interested in. angle are:
• Master Maintenance processes - Typically • Reports and Query Screens of critical data,
master maintenance processes on a legacy alerts, KPIs, etc
system would define some of the major • Views
data repositories in the system. By • Processes that receive data from systems
reviewing the Master Maintenance options other than the legacy platform e.g. EDI
available in Legacy systems we can define
o Identify “Data Collation” processes others – either within the organization or outside
the organization.
Very often it has been observed that critical
decision-making logic is embedded in data • Data Archival Processes (What to
collation processes such as: backup, With what frequency and Where
to store the archives)
• Day-End Processes • Disaster Recovery Processes (How to
• Month-End Processes recover from a Disaster)
• Year-End Processes • Business Continuity Processes (How
• Triggers to continue business in the face of a
• Stored Procedures disaster)

It has also been observed that more often than However, consciously looking through such
not this decision-making logic – which typically processes and consciously deciding that none
reflects the way the business operates – is of it is going to be useful as a service is an
embedded deep in code. By evaluating such extremely important step when you do not
legacy programs we might identify logic that is want to miss any possible candidate services.
better packaged as a service so that it is easier to
change without fear of accidentally disrupting a ii. Map the business process with supporting
whole lot other areas of these processes. manual processes
Packaging logic into services can help not only
from the perspective of re-usability but also from In many businesses, in spite of wide-spread
easy maintainability. computerization, manual processes have not
disappeared totally. The services that are being
o Identify “Application Support” Processes envisaged need to be reviewed with respect to the
manual processes to determine:
Many legacy systems lack the functionality to
efficiently interact with support processes such
o Can the services reduce manual processes?
as Work-Flow processes. This is typically
because transactions that can and should get o If not, how can the services at least facilitate
triggered based on a task’s progress in the work- or optimize the manual processes?
flow system are too heavily enmeshed within the
existing code. By thinking of the AS-IS and TO- It might so happen that these deliberations itself
BE from the Work-Flow perspective – can give rise to new or modified processes – and
irrespective of whether one has or does not have hence services.
a work flow application – one can identify those
pieces of the legacy application that can be iii. Identify the functions that are the constituent
extracted into services which can be used to parts of the identified business process in the
build a more robust work flow process. system
o Identify “Database Support” Processes
o Decompose the identified processes to finer-
Most of the legacy systems are characterized by grain functions that happen within those
tens or hundreds of programs writing data to processes
critical tables. This is a definite problem when a
change is to be implemented in the way data is iv. For each identified business function in the
currently being written. This problem could be system:
alleviated by identifying the scope and utility of
wrapper services that act as the ONLY way to
send or retrieve data from database tables. o Analyze function for re-usability.

o Identify “Technology Support” Processes
If neither the function nor the business
processes is re-usable probably there is not
Typically technology support processes such as much candidacy for creating a service. If
those mentioned below would not yield any re- function is not re-usable but business process
usable services that one would want to expose to is re-usable, analyze if the function would be
impacted if the business process is made into
 service. If yes then, probably there is not 3. Creating Services derived from Legacy
much candidacy for creating a service. Applications
o Identify where similar functions are repeated
in the Legacy application - If multiple Note: As noted earlier in Part II, this section does not
occurrences are found, analyze each attempt to provide a comprehensive coverage of SOA-
occurrence for similarities and differences. related topics such as Governance, Performance,
o Analyze if the similarities are significant Security, Testing, etc. Instead it is just an example of
enough and the differences are NOT implementing a service mined from legacy iSeries
significant enough to conceptualize a generic application and brought out as a web service. We have
function that can address both requirements chosen web service as a representative method of
with minor (if any) changes, ex. adding a implementing SOA. There can be other implementations
process type parameter. of SOA.

o Apart from the main programs itself, possible In the example that we have attempted, we extracted the
candidates could be found in: Player (i.e. Customer) Rating logic from an iSeries-based
• Copy Books Casino Management System and made it available as a
• Service Programs web service. In this section, we highlight some of the
considerations that went into this process.
• Modules
o Envision a new module of proper granularity Once functionality has been identified as a suitable
and generality candidate for converting into service, it is best to
o This new module should execute only one determine how the business logic can be disconnected
function related to any one of the following from the original user interface and made into a self
needs - Business Needs, Technical Needs, contained subprogram wherein the original input
Application Needs, Database Needs arguments will be represented as input parameters and the
original output arguments would be represented as output
o Based on the specific needs, identify the parameters. One approach for achieving this could be to
interface for the module. create a separate version of the function that is devoid of
o Create the module implementing various all user-interface (UI) related items (ex. Messages,
SOA requirements Prompts, input and output fields on the screen, etc). This
can be attempted for simple functions. However, if it is
o Package the module(s) into re-usable services perceived that this process is not trivial and might
introduce risks, then an alternative approach might be to
v. Sufficiency of Services utilize products such as look software that convert
interactive programs to run in batch. This would enable
o Ensure all Services and identified business the calling routines to use the existing program without
process are together sufficient for conducting worrying about possible problems due to the presence of
the business of the domain UI components. In either case, the end result will be a
subroutine with a call interface.
C. CROSS-DOMAIN SERVICE VERIFICATION
The next step is to wrap this sub-routine into a Web
Services Description Language (WSDL) interface,
For each domain perform the following verification- providing a proxy to it on the application server and,
related steps. finally, making it discoverable by making it available on
Universal Description, Discovery, and Integration
• Identify which business processes interface with (UDDI) or equivalent tools that allow callers to search for
other domains available services. Web Sphere Studio Client for iSeries
• Analyze nature of cross-domain interface (WDSCi) was the IDE tool used for this purpose.
• Analyze the data being interchanged across the Attached below is a screen snapshot of WDSCi IDE
interface for the following factors: Consistency, depicting various facets of the end product viz. Sources
Correctness, Adequacy, Recovery, Message generated, input parameters and output XML.
flows.
 Example Screenshot of Deployment of Service Using WDSCi

4. Conclusion [1] Adapting legacy systems for SOA - Finding new business value
in older applications - Calvin Lawrence, IBM
http://www.ibm.com/developerworks/webservices/library/ws-
In this paper we have attempted to define some of the critical soa-adaptleg/
activities and decision points that are integral to identification [2] Towards Legacy Enablement Using SOA and Web Services
and extraction of services from Legacy applications. Brief http://webservices.sys-con.com/read/164558.htm
overviews of sign-posts identified in this article are: (a) [3] Service Oriented Architecture
Functions that handle critical business services (b) Functions http://en.wikipedia.org/wiki/Service-oriented_architecture
critical for ensuring data integrity and consistency. [4] OASIS
http://en.wikipedia.org/wiki/OASIS_SOA_Reference_Model
[5] Service-Oriented Architecture (SOA): Concepts, Technology,
5. Future Scope and Design (The Prentice Hall Service-Oriented Computing
Series from Thomas Erl) http://www.amazon.com/Service-
Oriented-Architecture-SOA-Technology-
As an extension to this work, we would like to develop a
Computing/dp/0131858580
similar guideline document especially from the perspective of [6] Unlocking the Mainframe
how the presence of Legacy Application can influence SOA www.bea.com/content/news_events/white_papers/BEA_Unlocki
features such as Governance, Quality, Security, and Testing. ng_Mainframe_wp.pdf
[7] Web Sphere Development Studio – Basics
http://search400.techtarget.com/sDefinition/0,,sid3_gci1164479,
6. References 00.html