Extending COBOL to SOA,

Web Services and Beyond

A Look at the Architecture

White Paper
Abstract
Not that long ago, businesses were scrambling to find a method of quickly
extending their legacy applications to the Web. A variety of tactical Web-
enablement technologies were used to meet that requirement, but most of
these extension solutions were implemented as short-term, stop-gap responses
to an immediate need. In many cases the resulting deployment infrastructures
are fragile, failure-prone and inflexible. Until recently most extension solutions
focused primarily on exposing legacy transactions, not business processes.
Today’s business environment has moved beyond the need to simply expose
legacy transactions.

With the Micro Focus product line, organizations have the best tools to extend
COBOL applications and support the flexibility demands of Service Oriented
Architecture (SOA). In this paper we will take a look at how COBOL transactions
are transformed into business services and deployed in an SOA environment.
Contents
Introduction ............................................................................................................................ 2
Micro Focus Pedigree...................................................................................................... 2
Micro Focus, SOAs and Web Services ............................................................................ 2
COBOL ‘Services’ ..................................................................................................................... 3
Introduction to Services.................................................................................................. 3
The Value of SOA ............................................................................................................ 3
COBOL Business Processes and SOA .............................................................................. 4
Building a COBOL based Service........................................................................................... 6
Introduction..................................................................................................................... 6
Service Discovery ............................................................................................................. 6
Service Definition ............................................................................................................ 6
Service Generation .......................................................................................................... 9
Publishing and Deployment.........................................................................................11
Mainframe CICS Deployment Architecture .......................................................................12
Mainframe Deployment ...............................................................................................12
Application Server Deployment ..................................................................................12
Runtime Process Flow ...................................................................................................14
Mainframe IMS Deployment Architecture ........................................................................15
Mainframe Deployment ...............................................................................................15
Application Server Deployment ..................................................................................16
Runtime Process Flow ...................................................................................................16
Distributed COBOL Deployment Architecture ..................................................................17
Micro Focus Server Deployment ..................................................................................17
Application Server Deployment ..................................................................................18
Runtime Process Flow ...................................................................................................18
A Solution that Benefits the Enterprise.............................................................................19
Technology Benefits .....................................................................................................19
Business Benefits ...........................................................................................................19
Summary................................................................................................................................20
References.............................................................................................................................21

1
Introduction
Most businesses have come to realize the value of reusing the existing business
processes locked within their COBOL applications. They have moved beyond ‘rip and
replace’ to the more practical leverage and extend school of thought which advocates
recycling proven processes in combination with newer technologies to satisfy current
and future business needs. Rather than extolling the virtues of COBOL extension as
business services, this paper focuses on creating the services as well as the strategic
systems architecture exploited by Micro Focus products to deliver renewed business
value from existing COBOL applications running on either mainframe or distributed
platforms.

Micro Focus Pedigree

Founded in 1976, Micro Focus has over 30 years of experience in COBOL analysis and
development technology, primarily focused in two areas:

• Development, extension and deployment of COBOL applications on Open

Systems architectures where Micro Focus COBOL is the de-facto industry
standard on Windows and UNIX.
• Development of IBM mainframe applications using workstation-based
technology to offload analysis, and the development and maintenance
activities from the mainframe. Hundreds of major corporations worldwide
today are using Micro Focus technology to create and maintain mainframe
COBOL applications.

Over the last two decades Micro Focus has produced the most comprehensive,
state-of-the-art Integrated Development Environments (IDEs) for COBOL.

Micro Focus, SOAs and Web Services

While perhaps not the most obvious vendor that comes to mind when Web services are
mentioned, Micro Focus has a long and distinguished history in this area. A respected
member of the Web Services Interoperability Organization since its inception in 2002,
Micro Focus continues to participate as a leading member of this organization helping
to drive the future of interoperable Web services.

2
COBOL ‘Services’
Introduction to Services
Simply put, a service is a standalone unit of work that is invoked to achieve a desired
outcome such as assemble and display a user interface or process a business
transaction. While you may read a lengthy textbook that describes this in painful
detail, it is at the conceptual level that a ‘service’ has most value: a set of discrete
activities that the business can use, and reuse, easily and simply, to attain required
outcomes with minimum of cost and risk.

You’ll have heard, no doubt, of component-based-architecture, or object oriented

development, or classes and methods. You might also have heard of modular
programming, of stepwise refinement, or of loose-coupling. We won’t attempt to
re-define these terms here, but what we will do is acknowledge they were all attempts
to define and solve one key problem – software reuse.

These ideas tried to tackle the issue of trying to make things re-useable from a
technical, or programming, perspective. They were all ingenious ideas, but in most
cases, also impracticable. Largely because the very objective trying to be achieved,
that of reuse, was untenable because those who could determine effective reusability
at a business level, did not or could not understand the level of functionality being
made available for reuse. That is, it was too detailed, too ‘fine-grain’, or too specific.

By defining the building block of required reuse to be a service, one naturally tends
toward a more coarse-grained view of the world. A service could be ‘get me the total
amount of cash a client has in their accounts at this bank’, ‘credit score this person’, ‘let
someone order a product online’, or ‘process this online loan application and return
the answer instantaneously’. These are all examples of services and could be a unique
part of the way a business runs. Having a method of exploiting, reusing and
maximizing the value of these services, is largely the whole point of SOA.

The Value of SOA

The benefits of building service-based architectures are legion. From creating a more
efficient development process to increased cost savings and risk mitigation, the
advantages of moving to service architectures are well documented. Gartner have
estimated that service-based development of applications can reduce total IT expenses
over the long term by as much as 20 percent [1] when compared to more traditional
development methods. These savings become even greater over time as the library of
business services expands and a greater degree of reuse can be achieved with those
services.

There are any numbers of papers, books, seminars and conferences extolling these
virtues which go into far greater detail than is possible here, but a generally accepted
set of benefits of moving to SOA consists of the following items:

• More efficient development process

• Independence from the technology
• Evolutionary approach
• Reuse of existing assets
3
 • Risk mitigation
• Improved business infrastructure
• Increased agility
• Faster time to market
• Improved return on investment

We are going to concentrate on just one of these benefits, probably one of the least
well understood and talked about benefit in fact, is that of leveraging the investment
which has been made in mainframe assets. This is for a very good reason. It’s difficult.

All too often you read in the press about the latest company that has decided to
rewrite all the software that runs their business using the latest technology. In effect
they are betting the company on the success or failure of this venture. And as is often
seen, a complete rewrite has a multitude of unforeseen consequences leading to
potentially embarrassing headlines. Those mainframe assets are still relied on in a
production environment and that’s because they do exactly what they are supposed
to. Reusing those assets with as little change to them as possible will result in an
architecture that is still based upon the same business processes as you use today.

With some 200 billion lines of COBOL code currently in production in the world today,
it is a fairly safe assertion that this code makes up the heart of an enterprise’s IT
systems. It is these IT systems reflecting business processes that are going to be critical
going forward into a service based future. Let’s take a look at just why the COBOL
business processes are so important to creating a successful SOA.

COBOL Business Processes and SOA

Some programming languages are better at satisfying certain tasks than others.
For example, Java and C-type languages are well suited for presentation control and
application behaviours, while COBOL is better for defining and applying the rules of
business. Therefore it is very often the case, especially in established and large-scale
applications, that is the COBOL-based processing that needs to be exploited to deliver
the value of business services within an SOA.

In essence, it is a collection of COBOL transactions that satisfy a particular business

need. Whether validating insurance coverage, getting a cumulative total of account
balances, or looking up a medical history, the task is usually achieved by invoking a
series of transactions in step with some kind of data (see Figure 1).

Whether a business process is comprised of one or more transactions running in COBOL

is of no interest to those who require the service, what is important is the business
process being modeled within the COBOL application (the transactions, screens, data
access, flow of control, logic, calculations, etc). The underlying language that this
business process was written in should remain completely transparent to them. This is
the valuable nugget that we want to reuse, this ‘business process’, stored in COBOL.
How we achieve this, how we unravel the COBOL application to find the services we
need, and somehow dust them down for a new life as a service, to be explored in the
next sections.

4
Figure 1 – Legacy transactions at the heart of business services.

5
Building a COBOL-based Service

Introduction
This section explores how existing COBOL application information can be assessed,
understood and reused to develop services that will be suitable for building into an
SOA framework. Where required, supporting technology from the Micro Focus
product range will be described. Whenever a service is created, whatever the
language or platform of the originating code, a four steps process is usually employed.
The four steps process consists of Discovery, Definition, Generation and Deployment of
a service before it can be consumed by a client. The process is described below.

Service Discovery
Micro Focus Revolve® provides a powerful analysis tool for developers with a
comprehensive view of their applications’ complexity and interdependencies. This
capability can be used to quickly identify which existing transactions perform the
various functions that are combined to meet the business requirements of a service.
This is the first step to transforming discrete COBOL transactions into complete units of
work. In this preliminary step, developers use Analysis Option in Revolve to:

• Determine which existing COBOL transactions are required to perform a specific

business service – both screen and COMMAREA based programs.
• Identify the input and output (I/O) fields that are used to execute the service –
not only user input, but also any programmatic input that may result from a
previous transaction(s).
• Establish the transaction invocation workflow to satisfy the service
requirements – that is, the sequence in which existing transactions must be
executed to perform the business objective.

Service Definition
Having identified the transactional and I/O data requirements of a business service,
one of two facilities are used to define the transactional steps for creating a business
service depending on where the application and service will ultimately be deployed.

• The Component Generator feature of Mainframe Express™ Enterprise Edition is

used to create services for applications that will remain on the mainframe
(Figure 2).
• The Interface Mapping Toolkit feature of Net Express® is used to create services
for applications that have or will be migrated to a distributed platform and
executed on Micro Focus Server™ (Figure 3).

6
Figure 2 – The Component Generator feature of Mainframe Express Enterprise Edition is used to create
COBOL services for applications that run on the mainframe.

Regardless of the target platform, this ‘interface painting’ process is accomplished via a
‘drag and drop’ coding paradigm. In this second step of building COBOL business
services, developers use Micro Focus products to:

• Define all the service steps and transaction workflow – that is, which
transaction is invoked first, second, third, etc. – as well as what actions to take if
any of the existing transactions or the overall business process fails. There is no
limit to the number of transactions that can be combined as part of a service.
In fact, it is even possible to invoke transactions out of their ‘normal’ sequence
– enabling ‘old’ transactions to be combined in new ways to meet changing
business needs.
• Define the interface fields of the service – which fields need to be populated
for each transaction and where they are obtained so that all required data can
be collected up front. For example, to open a new account, one may need to
traverse multiple entry screens. Therefore, to expose this as a standalone
service, all the input data must be collected prior to invocation. Furthermore,
there may be output results from one screen/transaction required as input to a
following transaction, so the ability to move data to temporary “work fields”
for use in later transactions can also be provided.

7
 • In some cases, the service you are creating may have requirements that are not
native to the existing application. Suppose you are creating a service to
retrieve the balances for all accounts held by an individual, as well as a ‘total
balance’ of the various account balances. To do this, you may have to invoke
multiple unrelated transactions and then perform an addition operation to
return the cumulative result. Micro Focus products provide facilities to perform
additional functions within the COBOL service, such as loop constructs to parse
tabled data, conditional logic for determining what actions need to be taken
based on transaction output results, mathematical operations for manipulating
data prior to delivering to the requestor or as input to following transactions,
and other such similar programming logic.
• Some organizations may have a need to access their data without using their
existing legacy application. Let’s say you want to get a list of medical providers
for a particular region and to achieve this using existing application logic
requires you to traverse several menus to get to the search screen. For
applications remaining on the mainframe, Micro Focus products allow you to
create Data Access services that accept search criteria, access data sources and
provide results output without using any legacy code and providing standard
read/write/update/delete restrictions.
• Once your service has been defined and painted, a project property sheet is
used to select the technology platform(s) you need to support, such as
middleware properties, component type, and application server specifics.
Supported target technologies include mainframe and distributed COBOL,
IBM® WebSphere MQ and IBM CICS Transaction Gateway (ECI) middleware
protocols, J2EE, .NET and Web service component interfaces, and all leading
Java application servers. After making your selections, you are ready to
generate your business service.

Figure 3 – The Interface Mapping Toolkit feature of Net Express is used to create COBOL services for
applications that run on distributed platforms under Micro Focus Server.

8
Service Generation
One of the distinct advantages of this solution is the ability to generate all of the
infrastructure plumbing required to convert your COBOL transactions into business
services. This means that COBOL developers do not need to know the intricacies of the
underlying technology, such as MQ protocols, Java or C# programming, application
server minutiae, and so on. This frees the developers from the burden of debugging
technology interfacing issues and instead allows them to concentrate on delivering the
real business value – ubiquitous business services. This also means that organizations
need not expend limited resources on training programs to bring COBOL developers
up-to-speed on contemporary technologies (those resources can be put to better use
elsewhere) nor is it necessary to cope with and resolve the technology gap issues one
encounters when coordinating development teams of differing cultures – COBOL vs.
Java for example. With this solution from Micro Focus, the COBOL developer can
identify, generate and test Java or C-based services end-to-end and simply ‘throw them
over the wall’ to front-end teams (or external partners/customers) for assembly into
their new applications.

Figure 4 – Service Generated Module accessing mainframe COBOL transactions.

When a service is generated within the IDE, the key infrastructure components are
common to every service although the exact details are dependent upon which
platform the service is to be deployed on. There are two main components created by
the generation process by the IDE and they are:

9
 • COBOL Service Module

The COBOL Service Module orchestrates the execution flow of COBOL

transactions, passing any required data when it is needed by a service to and
from the existing COBOL transactions, be they CICS, IMS or Data. It is important
to note that the COBOL Service Module does not duplicate any existing logic
nor require any changes to the existing transactions. This Service Module is a
standard COBOL program which invokes the required transactions (Figure 4) or
in the case of data access services (Figure 5), will access the data source, be it
DB2, VSAM or IMS DB.

• Industry-standard Service Component

The Service Component is the part which collects the data from the user
interface and sends it to the COBOL Service Module. Any results from the
service will be received and sent back to the original requestor. The Service
Component is capable of running on any standard J2EE or .NET platform and
will be the component that is invoked from the original client code. The exact
composition of the Service Component will depend upon the deployment
choices made within the IDE.

Figure 5 – Service Generated Module accessing mainframe data directly.

10
Publishing and Deployment
Once you have defined and generated your services, they need to be deployed so they
can be used by third-party applications. These third-party applications can be either
existing or brand new applications that wish to take advantage of the freshly exposed
business service. Of course, it’s not much good deploying your brand new services and
then not telling anyone about them, so you also have to publish your service so
everyone knows where to find it, what it does and how to use it. Think of it as a kind
of marketing campaign for your service! Although traditionally, services are intended
to be consumed by anyone, in reality, most services today are being utilized internally
within an organization or even a department. This still means though that they need
to be published so that the contract can be agreed between the service provider and
the service consumer.

So what actually happens when a service is deployed? Well, simply put, the software
artifacts that were created as part of the previous step, service generation, are
installed into their relevant locations on the mainframe and application server. In
addition, any publication of the new service to a relevant UDDI registry is also handled
by the toolkit in a simple manner. Although the deployment and publication process
sounds complicated, Micro Focus tools have been specifically designed to help guide
the deployment without requiring in-depth technical knowledge of each and every
aspect of the target platform. It is likely that COBOL programmers or even business
analysts will be used to define services from the original business processes using an
IDE and it would be an unreasonable expectation for them to understand all the
intricacies involved in every area of an SOA deployment. There shouldn’t be a
requirement for them to have to learn how to be systems programmers familiar with
J2EE, WebSphere or IIS configuration in addition to their main job function of
applications programming. People with such a broad range of experience are few and
far between in the industry and are like gold dust.

The beauty of Micro Focus development tools solution is that the toolkits handle the
complex middleware parts by building and deploying industry standard components,
which can then be consumed by any other toolkit. Micro Focus deployed Web services
are defined with all the relevant Web services standards and are compliant with the
gold standard of interoperability, the Basic Profile 1.0 [2] as laid down by the Web
Services Interoperability Organization (http://www.ws-i.org).

Reducing the complexity of deploying and publishing a COBOL service to a suitable

platform helps enormously when rapidly trying to create a service based architecture.
Very often this step can hinder a rapid successful roll-out of exposing COBOL services
to a wider community. It is important to note though that the applications and
programmers that utilize the service, the service consumers do not need to know the
internals of the service that they are calling. Indeed, it is extremely unlikely that the
service consumers will ever realize that they are calling a COBOL service at all.

11
Mainframe CICS Deployment Architecture
This section describes how the services generated from Mainframe Express Enterprise
Edition are deployed to position mainframe CICS applications as high-volume business
service providers (please refer to Figure 6).

Mainframe Deployment
The mainframe deployment requirements for providing COBOL-based business services
are really quite simple. The existing CICS application remains completely unchanged
on the mainframe and will be ‘driven’ by a COBOL Service Module created when the
service was generated. You will recall from the previous section that for every business
service you wish to expose, a COBOL Service module is generated to orchestrate the
activity of the existing CICS transactions in the application. To expose the business
services embedded in the CICS application, the following operations need to be
performed:

• Generated COBOL Service Module(s) must be uploaded and reside within the
existing application’s CICS region.
• Component Generator Server must be deployed to the mainframe so that the
COBOL Service Modules can be instantiated when a service needs to invoke
one. This facility is deployed only once and runs as a started task under CICS.
Its function is to manage middleware communication between Service Modules
and their corresponding Service Components, interface between Service
Modules and IBM’s 3270 bridge or Link3270 bridge, as well as the runtime
lifecycle of Service Modules. When the same service is requested from multiple
sources, the server instantiates a new, independent copy of the COBOL Service
Module – this ensures scalability for high transaction volumes.

Application Server Deployment

When the service was generated, a number of middle tier components were created
which have to be deployed to the application server that is going to be used.
Depending upon which target application server is to be used, these middle tier
artifacts may be JavaBeans, EJBs or .NET components. Micro Focus allows for
automatic deployment to WebSphere, BEA WebLogic, Apache Tomcat, Oracle®
Application Server and Microsoft IIS, but this auto deployment can easily be extended
to other third party application servers should it be so desired.

Once these middle tier components have been deployed, they can be accessed via a
wide range of clients. These clients include JSP pages in a web browser, WAP enabled
or MIDP compliant mobile device, any Java application, .NET C# application and, of
course, a Web service client. As Micro Focus is generating industry standard middle
tier components, they can be accessed from pretty much any client application you
would wish to.

12
An important feature of all Micro Focus products is the ease of testing that the user is
empowered with, and this one is no exception. Simple test clients can be generated to
allow for thorough testing of your newly created service, whether it is an eBiz or a
Data Access Transaction. These test clients should be used to verify that your service
does everything you require of it before you start to write your own clients.

When deploying a Web service, you also have the ability to publish the WSDL (Web
Service Description Language) file to a UDDI (Universal Description, Discovery and
Integration) registry. The WSDL file is the contract for your Web service and is what
required to be consumed so that a Web service client can be created. Micro Focus
allows full configuration to allow publication to any UDDI registry that is available. In
the early days of Web services, a number of companies (Microsoft, IBM, SAP and HP) all
maintained public UDDI registries for testing purposes, but most of these have now
closed as the technology has matured. Today, most UDDI registries are privately run
and only visible on a company Intranet as many Web services deal with commercially
sensitive data.

Figure 6 – Architectural view of a service enabled CICS application deployed on the mainframe.

13
Runtime Process Flow
When a request for mainframe CICS service is made, the overall process flow will
consist of the following steps:

1) Request is made by the composite application, activating a generated service

component on J2EE or .NET application server.

2) Data collected from the user interface is transmitted via MQ or ECI to the
middleware interface on the mainframe by the service component.

3) The generated COBOL Service Module is instantiated on the mainframe and

invokes the existing legacy transactions that satisfy the business request. Depending
on what type of Service Module was created for the service will result in one of three
flows taken here:
® 3270-based transactions are accessed using IBM 3270 bridge or Link3270 bridge
and executed as defined in our defined service.
® COMMAREA-based transactions are executed via CICS LINK.
® Data Access transactions attach directly to the data source using the generated
COBOL data module and by passing the existing applications.

4) Once the existing transactions have completed, any results (success or failure) are
marshalled via the middleware interface back to service component on the application
server.

5) The application server component output is then provided back to the requestor
client.

14
Mainframe IMS Deployment Architecture
This section describes how services generated from Mainframe Express Enterprise
Edition are deployed to position mainframe IMS applications as high volume
business service providers (please refer to Figure 7).

Mainframe Deployment
Similar to mainframe CICS deployment, the requirements for providing IMS-based
business services are also quite simple. Again, existing IMS applications will
remain completely unchanged on the mainframe and will be ‘driven’ using a
generated COBOL Service Module. There will be one COBOL Service Module for
every business service that you wish to expose, which will coordinate the
orchestration of the activity of the existing transactions in the application. In
order to expose the business services contained within the IMS application, the
following operations need to be performed:

• Generated COBOL Service Module needs to be deployed to z/OS and it will

run under a dependent address space.
• Middleware Interface Runtime Server must be deployed to the mainframe
and be running as a task under z/OS. This component manages the
middleware communication between the COBOL Service Module and a
Service Component, instantiating a new, independent COBOL Service
Module for each request. This enables high scalability to provide for high
transaction volumes.

Figure 7 – Architectural view of a service enabled IMS application deployed on the mainframe.

15
Application Server Deployment
The generated components for a mainframe IMS service also have to be deployed
to the middle tier application server. Again, depending upon what target
application server is going to be used the exact middle tier artifacts will be
different. As for CICS deployment, Micro Focus allows for automatic deployment
to IBM WebSphere, BEA WebLogic, Apache Tomcat, Oracle Application Server and
Microsoft IIS, as well as allowing for custom auto deployment on other third-party
application servers.

In the same way as any CICS service, these middle tier components can be accessed
via the same wide range of clients, including JSP pages, WAP/MIDP compliant
mobile devices, Java and C# programs and, of course, anything that consumes a
Web service. Just as before, simple test clients can be generated to allow the
testing of the newly created service.

With any IMS service deployed to the mainframe, you also have the ability to
publish the WSDL (Web Service Description Language) file to a UDDI (Universal
Description, Discovery and Integration) registry. This functionality is exactly the
same as that for a mainframe deployed CICS service.

Runtime Process Flow

When a request for a mainframe IMS transaction is made from a client, the
process flow at runtime will consist of the following steps:

1) A client request is made from the composite application, activating a generated

service component on the J2EE or .NET application server.

2) Any data collected from the user interface of the client is transmitted via MQ to
the middleware interface on mainframe by the service component.

3) Generated COBOL Service Module is instantiated on the mainframe to control the

full set of transactions that satisfy the business service. Using OTMA (Open
Transaction Manager Access), the service module invokes existing transactions in the
IMS region. Any data access is still performed by the existing IMS 3270 transactions.

4) Once the existing transactions have completed, any results (success or failure) are
marshalled via the middleware interface back to service component on the
application server.

5) The application server component output is then provided back to the requestor
client.

16
Distributed COBOL Deployment Architecture
This section describes the components generated are deployed for use in the
distributed COBOL solution when applications are executing under the control of
the Micro Focus Server. Services are created in a functionally equivalent manner
to those created for deployment on the mainframe; but in this case, a tool named
the IMTK (Interface Mapping Tool Kit) is used rather than the Component
Generator. For this section, refer to Figure 8 for a pictorial representation of the
deployment architecture.

Micro Focus Server Deployment

It must be remembered that an application running under Micro Focus Server will
already have been migrated to run off the mainframe. Therefore, there will be no
mainframe specific components that need to be deployed to a mainframe, as we
don’t need one. Instead, some components will need to be deployed to the Micro
Focus Server. In a migrated application, just like on the mainframe, it is likely that
the existing CICS transactions will be substantially unchanged and the COBOL
Service Module that is created when the service is generated will ‘drive’ the
application using 3270 bridge technology. Just as before, a COBOL Service
Module is generated for each service you wish to expose. For each service that is
created for Micro Focus Server, the following component will be deployed:

• A generated COBOL service module within the existing application’s CICS

region will be deployed to Micro Focus Server.

Figure 8 – Architectural view of a service enabled mainframe application deployed on Micro Focus Server.

17
Application Server Deployment
As Micro Focus Server also acts as the application server, then any ‘middle tier’
components that are required to execute the service are deployed here. Micro
Focus Server has both SOAP and binary protocol request handlers built in so that
Web services and Java components can communicate directly.

Any SOAP requests are handled by the Micro Focus SOAP handler in a fully
standards compliant manner. For Web services, the SOAP handler is WS-I Basic
Profile 1.0 compliant meaning that Micro Focus deployed Web services are likely
to interoperate with third-party Web service clients. The binary protocol handler
allows for Java and .NET components to invoke services deployed on Micro Focus
Server with all the appropriate conversions performed automatically between the
Java and COBOL data types.

Just like a mainframe CICS or IMS service, deploying a Micro Focus Server hosted
service is a simple one-click process allowing for quick and easy deployment. Once
deployed, the service is ready to be invoked from a Java, .NET or Web service
client.

Runtime Process Flow

When a request for a service deployed under the Micro Focus Server is made from
a third party client then the following steps are followed:

1) A request is made from a composite application which activates a generated

service component:

• If the request is a Web service, the request and data are handled by the
SOAP request handler provided in Micro Focus Server
• If the request is from a J2EE component or a .NET class, the request and
data are handled by the Binary Protocol Request Handler provided in Micro
Focus Server
2) The generated COBOL Service Module is instantiated and invokes existing
transactions that satisfy the business request.

• The 3270-based transactions are accessed using the 3270 Bridge built into
Micro Focus Server.
• COMMAREA-based transactions are invoked via regular program calls.
3) Once existing the transactions have completed, the results (success or failure) are
marshalled back via the request handlers to the service component.

4) Application server component output is then provided back to the requestor

client.

18
A Solution that Benefits the Enterprise
Micro Focus Server delivers a high performance solution for extending existing
COBOL applications with services supporting SOA best practices and adhering to
established industry standards. Using Micro Focus products allow you to take a
strategic approach for both mainframe and distributed legacy applications.

Technology Benefits
• Micro Focus development products make it easy for developers to identify,
define, create and test COBOL-based business services that support
standard SOA implementations.
• Instead of using the mainframe for analysis, generation, compilation,
debugging and unit testing activities, developers can utilize the
workstation for these activities, thereby reducing costly mainframe cycles.
• Developers can use state-of-the-art workstation based user interfaces to
improve their productivity in creating applications.
• Infrastructure, language protocols and complexities are hidden from
developers, enabling them to focus on delivering business services quickly
rather than debugging code and communication errors.
• Re-usable services supporting loosely-coupled applications deliver
unprecedented flexibility and preparedness for change.

Business Benefits
• Extension of existing mainframe transactions without any requiring any
code changes allows a quick and easy exposure of mainframe assets.
• Micro Focus tools make it easy to define services from existing mainframe
technology, with no code changes, consolidating the investment in proven
code.
• Low risk approach to leveraging existing investment in business processing
leads to a more efficient development process.
• Rapid development meets business requirements more quickly and at a
lower cost, while also improving customer satisfaction and loyalty.
• Ready to meet future business challenges head-on with a flexible and
adaptable supporting architecture.

19
Summary

All too often in the mad rush to explore the ‘next big thing’ in software
technology, businesses often forget the huge investment they already have in
their existing assets on the mainframe. These assets have been proven, often over
many years, or even decades, performing the business functions that they were
designed for. By leveraging the existing mainframe assets, together with the
flexibility of moving to a service-based architecture, significant cost savings will be
realized.

Micro Focus Server and IDE product range allows businesses to move to service
based architectures by extending their existing business assets in a non-intrusive
manner by making little or no code changes to those existing legacy applications.
Rather than perform a complete rewrite of the critical business functions that are
working today, these functions can be executed on the hardware platform they
were designed to run on.

As it is becoming more obvious to corporate visionaries, service orientation of

existing legacy assets is going to be a key differentiator for successful businesses in
the coming years. The fact that this revolution will be underpinned by the COBOL
language and related mainframe technology is a reflection of the importance that
COBOL has played within business systems over the past decades.

Author: Darren Self, Web Services Evangelist at Micro Focus

September 2006

20
References

[1] SODA Return on Investment Model Productivity Factors

Gartner Briefing – Michael Blechar, Matthew Hotle

[2] Web Services Interoperability Organization Basic Profile 1.0

http://www.ws-i.org/Profiles/BasicProfile-1.0-2004-04-16.html

21

Micro Focus - Unlocking the Value of Legacy™
Micro Focus is a leading provider of legacy
development and deployment software for
enterprise platforms. Micro Focus enables
organizations to reduce costs and increase agility
with minimal risk by reusing their legacy
applications with contemporary architectures and
Web services. Founded in 1976, Micro Focus is a
global company with principal offices in the
United Kingdom, United States, Germany and
Japan. For more information, visit
www.microfocus.com.
22
Micro Focus
Micro Focus Worldwide
Australia ............................ 1800 632 626
Austria ............................... 0800 293 535
Belgium ............................... 0800 11 282
Canada............................... 905 824 7397
France ................................ 0800 835 135
Germany .......................... 0800 182 5443
Italy ...................................... 800 784 420
Japan............................... 81 3 5793 8550
Luxembourg........................... 800 23743
Netherlands..................... 0800 022 8562
Norway ............................ 47 22 91 07 20
Switzerland ....................... 0800 564 247
United Kingdom ............ 0800 328 4967
United States..................... 877 772 4450
Other Countries .............. 44 1635 32646
© 2006 Micro Focus. All Rights Reserved.
Micro Focus, Net Express and Revolve are
registered trademarks, and Mainframe Express,
Micro Focus Server and Unlocking the Value of
Legacy are trademarks of Micro Focus. Other
trademarks are the property of their respective
owners.
WPSTWS1006-US