extending cobol to soa, web services and beyond - a look at the architecture

24
Extending COBOL to SOA, Web Services and Beyond A Look at the Architecture White Paper

Upload: manish-chowdhury

Post on 24-Mar-2015

68 views

Category:

Documents


7 download

TRANSCRIPT

Page 1: Extending COBOL to SOA, Web Services and Beyond - A Look at the Architecture

Extending COBOL to SOA,Web Services and Beyond

A Look at the Architecture

White Paper

Page 2: Extending COBOL to SOA, Web Services and Beyond - A Look at the Architecture

Abstract

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

With the Micro Focus product line, organizations have the best tools to extendCOBOL applications and support the flexibility demands of Service OrientedArchitecture (SOA). In this paper we will take a look at how COBOL transactionsare transformed into business services and deployed in an SOA environment.

Page 3: Extending COBOL to SOA, Web Services and Beyond - A Look at the Architecture

1

ContentsIntroduction ............................................................................................................................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

Page 4: Extending COBOL to SOA, Web Services and Beyond - A Look at the Architecture

2

IntroductionMost businesses have come to realize the value of reusing the existing businessprocesses locked within their COBOL applications. They have moved beyond ‘rip andreplace’ to the more practical leverage and extend school of thought which advocatesrecycling proven processes in combination with newer technologies to satisfy currentand future business needs. Rather than extolling the virtues of COBOL extension asbusiness services, this paper focuses on creating the services as well as the strategicsystems architecture exploited by Micro Focus products to deliver renewed businessvalue from existing COBOL applications running on either mainframe or distributedplatforms.

Micro Focus PedigreeFounded in 1976, Micro Focus has over 30 years of experience in COBOL analysis anddevelopment technology, primarily focused in two areas:

• Development, extension and deployment of COBOL applications on OpenSystems architectures where Micro Focus COBOL is the de-facto industrystandard on Windows and UNIX.

• Development of IBM mainframe applications using workstation-basedtechnology to offload analysis, and the development and maintenanceactivities from the mainframe. Hundreds of major corporations worldwidetoday are using Micro Focus technology to create and maintain mainframeCOBOL 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 ServicesWhile perhaps not the most obvious vendor that comes to mind when Web services arementioned, Micro Focus has a long and distinguished history in this area. A respectedmember of the Web Services Interoperability Organization since its inception in 2002,Micro Focus continues to participate as a leading member of this organization helpingto drive the future of interoperable Web services.

Page 5: Extending COBOL to SOA, Web Services and Beyond - A Look at the Architecture

3

COBOL ‘Services’Introduction to Services

Simply put, a service is a standalone unit of work that is invoked to achieve a desiredoutcome such as assemble and display a user interface or process a businesstransaction. While you may read a lengthy textbook that describes this in painfuldetail, it is at the conceptual level that a ‘service’ has most value: a set of discreteactivities that the business can use, and reuse, easily and simply, to attain requiredoutcomes with minimum of cost and risk.

You’ll have heard, no doubt, of component-based-architecture, or object orienteddevelopment, or classes and methods. You might also have heard of modularprogramming, of stepwise refinement, or of loose-coupling. We won’t attempt tore-define these terms here, but what we will do is acknowledge they were all attemptsto define and solve one key problem – software reuse.

These ideas tried to tackle the issue of trying to make things re-useable from atechnical, or programming, perspective. They were all ingenious ideas, but in mostcases, also impracticable. Largely because the very objective trying to be achieved,that of reuse, was untenable because those who could determine effective reusabilityat a business level, did not or could not understand the level of functionality beingmade 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 tendstoward a more coarse-grained view of the world. A service could be ‘get me the totalamount of cash a client has in their accounts at this bank’, ‘credit score this person’, ‘letsomeone order a product online’, or ‘process this online loan application and returnthe answer instantaneously’. These are all examples of services and could be a uniquepart of the way a business runs. Having a method of exploiting, reusing andmaximizing the value of these services, is largely the whole point of SOA.

The Value of SOAThe benefits of building service-based architectures are legion. From creating a moreefficient development process to increased cost savings and risk mitigation, theadvantages of moving to service architectures are well documented. Gartner haveestimated that service-based development of applications can reduce total IT expensesover the long term by as much as 20 percent [1] when compared to more traditionaldevelopment methods. These savings become even greater over time as the library ofbusiness services expands and a greater degree of reuse can be achieved with thoseservices.

There are any numbers of papers, books, seminars and conferences extolling thesevirtues which go into far greater detail than is possible here, but a generally acceptedset 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

Page 6: Extending COBOL to SOA, Web Services and Beyond - A Look at the Architecture

4

• 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 leastwell understood and talked about benefit in fact, is that of leveraging the investmentwhich 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 torewrite all the software that runs their business using the latest technology. In effectthey are betting the company on the success or failure of this venture. And as is oftenseen, a complete rewrite has a multitude of unforeseen consequences leading topotentially embarrassing headlines. Those mainframe assets are still relied on in aproduction environment and that’s because they do exactly what they are supposedto. Reusing those assets with as little change to them as possible will result in anarchitecture 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 ITsystems. It is these IT systems reflecting business processes that are going to be criticalgoing forward into a service based future. Let’s take a look at just why the COBOLbusiness processes are so important to creating a successful SOA.

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

In essence, it is a collection of COBOL transactions that satisfy a particular businessneed. Whether validating insurance coverage, getting a cumulative total of accountbalances, or looking up a medical history, the task is usually achieved by invoking aseries 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 COBOLis of no interest to those who require the service, what is important is the businessprocess being modeled within the COBOL application (the transactions, screens, dataaccess, flow of control, logic, calculations, etc). The underlying language that thisbusiness process was written in should remain completely transparent to them. This isthe 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 weneed, and somehow dust them down for a new life as a service, to be explored in thenext sections.

Page 7: Extending COBOL to SOA, Web Services and Beyond - A Look at the Architecture

5

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

Page 8: Extending COBOL to SOA, Web Services and Beyond - A Look at the Architecture

6

Building a COBOL-based Service

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

Service DiscoveryMicro Focus Revolve® provides a powerful analysis tool for developers with acomprehensive view of their applications’ complexity and interdependencies. Thiscapability can be used to quickly identify which existing transactions perform thevarious 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 ofwork. In this preliminary step, developers use Analysis Option in Revolve to:

• Determine which existing COBOL transactions are required to perform a specificbusiness 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 aprevious transaction(s).

• Establish the transaction invocation workflow to satisfy the servicerequirements – that is, the sequence in which existing transactions must beexecuted to perform the business objective.

Service DefinitionHaving 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 businessservice depending on where the application and service will ultimately be deployed.

• The Component Generator feature of Mainframe Express™ Enterprise Edition isused 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 servicesfor applications that have or will be migrated to a distributed platform andexecuted on Micro Focus Server™ (Figure 3).

Page 9: Extending COBOL to SOA, Web Services and Beyond - A Look at the Architecture

7

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 businessservices, developers use Micro Focus products to:

• Define all the service steps and transaction workflow – that is, whichtransaction is invoked first, second, third, etc. – as well as what actions to take ifany of the existing transactions or the overall business process fails. There is nolimit 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 changingbusiness needs.

• Define the interface fields of the service – which fields need to be populatedfor each transaction and where they are obtained so that all required data canbe collected up front. For example, to open a new account, one may need totraverse multiple entry screens. Therefore, to expose this as a standaloneservice, all the input data must be collected prior to invocation. Furthermore,there may be output results from one screen/transaction required as input to afollowing transaction, so the ability to move data to temporary “work fields”for use in later transactions can also be provided.

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

Page 10: Extending COBOL to SOA, Web Services and Beyond - A Look at the Architecture

8

• In some cases, the service you are creating may have requirements that are notnative to the existing application. Suppose you are creating a service toretrieve the balances for all accounts held by an individual, as well as a ‘totalbalance’ of the various account balances. To do this, you may have to invokemultiple unrelated transactions and then perform an addition operation toreturn the cumulative result. Micro Focus products provide facilities to performadditional functions within the COBOL service, such as loop constructs to parsetabled data, conditional logic for determining what actions need to be takenbased on transaction output results, mathematical operations for manipulatingdata 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 theirexisting legacy application. Let’s say you want to get a list of medical providersfor a particular region and to achieve this using existing application logicrequires you to traverse several menus to get to the search screen. Forapplications remaining on the mainframe, Micro Focus products allow you tocreate Data Access services that accept search criteria, access data sources andprovide results output without using any legacy code and providing standardread/write/update/delete restrictions.

• Once your service has been defined and painted, a project property sheet isused to select the technology platform(s) you need to support, such asmiddleware properties, component type, and application server specifics.Supported target technologies include mainframe and distributed COBOL,IBM® WebSphere MQ and IBM CICS Transaction Gateway (ECI) middlewareprotocols, J2EE, .NET and Web service component interfaces, and all leadingJava application servers. After making your selections, you are ready togenerate your business service.

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

Page 11: Extending COBOL to SOA, Web Services and Beyond - A Look at the Architecture

9

Service GenerationOne of the distinct advantages of this solution is the ability to generate all of theinfrastructure plumbing required to convert your COBOL transactions into businessservices. This means that COBOL developers do not need to know the intricacies of theunderlying technology, such as MQ protocols, Java or C# programming, applicationserver minutiae, and so on. This frees the developers from the burden of debuggingtechnology interfacing issues and instead allows them to concentrate on delivering thereal business value – ubiquitous business services. This also means that organizationsneed not expend limited resources on training programs to bring COBOL developersup-to-speed on contemporary technologies (those resources can be put to better useelsewhere) nor is it necessary to cope with and resolve the technology gap issues oneencounters when coordinating development teams of differing cultures – COBOL vs.Java for example. With this solution from Micro Focus, the COBOL developer canidentify, generate and test Java or C-based services end-to-end and simply ‘throw themover the wall’ to front-end teams (or external partners/customers) for assembly intotheir new applications.

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

Figure 4 – Service Generated Module accessing mainframe COBOL transactions.

Page 12: Extending COBOL to SOA, Web Services and Beyond - A Look at the Architecture

10

• COBOL Service Module

The COBOL Service Module orchestrates the execution flow of COBOLtransactions, passing any required data when it is needed by a service to andfrom the existing COBOL transactions, be they CICS, IMS or Data. It is importantto note that the COBOL Service Module does not duplicate any existing logicnor require any changes to the existing transactions. This Service Module is astandard COBOL program which invokes the required transactions (Figure 4) orin the case of data access services (Figure 5), will access the data source, be itDB2, VSAM or IMS DB.

• Industry-standard Service Component

The Service Component is the part which collects the data from the userinterface and sends it to the COBOL Service Module. Any results from theservice will be received and sent back to the original requestor. The ServiceComponent is capable of running on any standard J2EE or .NET platform andwill be the component that is invoked from the original client code. The exactcomposition of the Service Component will depend upon the deploymentchoices made within the IDE.

Figure 5 – Service Generated Module accessing mainframe data directly.

Page 13: Extending COBOL to SOA, Web Services and Beyond - A Look at the Architecture

11

Publishing and DeploymentOnce you have defined and generated your services, they need to be deployed so theycan be used by third-party applications. These third-party applications can be eitherexisting or brand new applications that wish to take advantage of the freshly exposedbusiness service. Of course, it’s not much good deploying your brand new services andthen not telling anyone about them, so you also have to publish your service soeveryone knows where to find it, what it does and how to use it. Think of it as a kindof marketing campaign for your service! Although traditionally, services are intendedto be consumed by anyone, in reality, most services today are being utilized internallywithin an organization or even a department. This still means though that they needto be published so that the contract can be agreed between the service provider andthe service consumer.

So what actually happens when a service is deployed? Well, simply put, the softwareartifacts that were created as part of the previous step, service generation, areinstalled into their relevant locations on the mainframe and application server. Inaddition, any publication of the new service to a relevant UDDI registry is also handledby the toolkit in a simple manner. Although the deployment and publication processsounds complicated, Micro Focus tools have been specifically designed to help guidethe deployment without requiring in-depth technical knowledge of each and everyaspect of the target platform. It is likely that COBOL programmers or even businessanalysts will be used to define services from the original business processes using anIDE and it would be an unreasonable expectation for them to understand all theintricacies involved in every area of an SOA deployment. There shouldn’t be arequirement for them to have to learn how to be systems programmers familiar withJ2EE, WebSphere or IIS configuration in addition to their main job function ofapplications programming. People with such a broad range of experience are few andfar between in the industry and are like gold dust.

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

Reducing the complexity of deploying and publishing a COBOL service to a suitableplatform 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 servicesto a wider community. It is important to note though that the applications andprogrammers that utilize the service, the service consumers do not need to know theinternals of the service that they are calling. Indeed, it is extremely unlikely that theservice consumers will ever realize that they are calling a COBOL service at all.

Page 14: Extending COBOL to SOA, Web Services and Beyond - A Look at the Architecture

12

Mainframe CICS Deployment ArchitectureThis section describes how the services generated from Mainframe Express EnterpriseEdition are deployed to position mainframe CICS applications as high-volume businessservice providers (please refer to Figure 6).

Mainframe DeploymentThe mainframe deployment requirements for providing COBOL-based business servicesare really quite simple. The existing CICS application remains completely unchangedon the mainframe and will be ‘driven’ by a COBOL Service Module created when theservice was generated. You will recall from the previous section that for every businessservice you wish to expose, a COBOL Service module is generated to orchestrate theactivity of the existing CICS transactions in the application. To expose the businessservices embedded in the CICS application, the following operations need to beperformed:

• Generated COBOL Service Module(s) must be uploaded and reside within theexisting application’s CICS region.

• Component Generator Server must be deployed to the mainframe so that theCOBOL Service Modules can be instantiated when a service needs to invokeone. This facility is deployed only once and runs as a started task under CICS.Its function is to manage middleware communication between Service Modulesand their corresponding Service Components, interface between ServiceModules and IBM’s 3270 bridge or Link3270 bridge, as well as the runtimelifecycle of Service Modules. When the same service is requested from multiplesources, the server instantiates a new, independent copy of the COBOL ServiceModule – this ensures scalability for high transaction volumes.

Application Server DeploymentWhen the service was generated, a number of middle tier components were createdwhich 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 tierartifacts may be JavaBeans, EJBs or .NET components. Micro Focus allows forautomatic deployment to WebSphere, BEA WebLogic, Apache Tomcat, Oracle®Application Server and Microsoft IIS, but this auto deployment can easily be extendedto other third party application servers should it be so desired.

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

Page 15: Extending COBOL to SOA, Web Services and Beyond - A Look at the Architecture

13

An important feature of all Micro Focus products is the ease of testing that the user isempowered with, and this one is no exception. Simple test clients can be generated toallow for thorough testing of your newly created service, whether it is an eBiz or aData Access Transaction. These test clients should be used to verify that your servicedoes 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 (WebService Description Language) file to a UDDI (Universal Description, Discovery andIntegration) registry. The WSDL file is the contract for your Web service and is whatrequired to be consumed so that a Web service client can be created. Micro Focusallows full configuration to allow publication to any UDDI registry that is available. Inthe early days of Web services, a number of companies (Microsoft, IBM, SAP and HP) allmaintained public UDDI registries for testing purposes, but most of these have nowclosed as the technology has matured. Today, most UDDI registries are privately runand only visible on a company Intranet as many Web services deal with commerciallysensitive data.

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

Page 16: Extending COBOL to SOA, Web Services and Beyond - A Look at the Architecture

14

Runtime Process FlowWhen a request for mainframe CICS service is made, the overall process flow willconsist of the following steps:

1) Request is made by the composite application, activating a generated servicecomponent on J2EE or .NET application server.

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

3) The generated COBOL Service Module is instantiated on the mainframe andinvokes the existing legacy transactions that satisfy the business request. Dependingon what type of Service Module was created for the service will result in one of threeflows taken here:

® 3270-based transactions are accessed using IBM 3270 bridge or Link3270 bridgeand 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 generatedCOBOL data module and by passing the existing applications.

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

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

Page 17: Extending COBOL to SOA, Web Services and Beyond - A Look at the Architecture

15

Mainframe IMS Deployment ArchitectureThis section describes how services generated from Mainframe Express EnterpriseEdition are deployed to position mainframe IMS applications as high volumebusiness service providers (please refer to Figure 7).

Mainframe DeploymentSimilar to mainframe CICS deployment, the requirements for providing IMS-basedbusiness services are also quite simple. Again, existing IMS applications willremain completely unchanged on the mainframe and will be ‘driven’ using agenerated COBOL Service Module. There will be one COBOL Service Module forevery business service that you wish to expose, which will coordinate theorchestration of the activity of the existing transactions in the application. Inorder to expose the business services contained within the IMS application, thefollowing operations need to be performed:

• Generated COBOL Service Module needs to be deployed to z/OS and it willrun under a dependent address space.

• Middleware Interface Runtime Server must be deployed to the mainframeand be running as a task under z/OS. This component manages themiddleware communication between the COBOL Service Module and aService Component, instantiating a new, independent COBOL ServiceModule for each request. This enables high scalability to provide for hightransaction volumes.

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

Page 18: Extending COBOL to SOA, Web Services and Beyond - A Look at the Architecture

16

Application Server DeploymentThe generated components for a mainframe IMS service also have to be deployedto the middle tier application server. Again, depending upon what targetapplication server is going to be used the exact middle tier artifacts will bedifferent. As for CICS deployment, Micro Focus allows for automatic deploymentto IBM WebSphere, BEA WebLogic, Apache Tomcat, Oracle Application Server andMicrosoft IIS, as well as allowing for custom auto deployment on other third-partyapplication servers.

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

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

Runtime Process FlowWhen a request for a mainframe IMS transaction is made from a client, theprocess flow at runtime will consist of the following steps:

1) A client request is made from the composite application, activating a generatedservice component on the J2EE or .NET application server.

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

3) Generated COBOL Service Module is instantiated on the mainframe to control thefull set of transactions that satisfy the business service. Using OTMA (OpenTransaction Manager Access), the service module invokes existing transactions in theIMS 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) aremarshalled via the middleware interface back to service component on theapplication server.

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

Page 19: Extending COBOL to SOA, Web Services and Beyond - A Look at the Architecture

17

Distributed COBOL Deployment ArchitectureThis section describes the components generated are deployed for use in thedistributed COBOL solution when applications are executing under the control ofthe Micro Focus Server. Services are created in a functionally equivalent mannerto those created for deployment on the mainframe; but in this case, a tool namedthe IMTK (Interface Mapping Tool Kit) is used rather than the ComponentGenerator. For this section, refer to Figure 8 for a pictorial representation of thedeployment architecture.

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

• A generated COBOL service module within the existing application’s CICSregion will be deployed to Micro Focus Server.

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

Page 20: Extending COBOL to SOA, Web Services and Beyond - A Look at the Architecture

18

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

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

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

Runtime Process FlowWhen a request for a service deployed under the Micro Focus Server is made froma third party client then the following steps are followed:

1) A request is made from a composite application which activates a generatedservice component:

• If the request is a Web service, the request and data are handled by theSOAP request handler provided in Micro Focus Server

• If the request is from a J2EE component or a .NET class, the request anddata are handled by the Binary Protocol Request Handler provided in MicroFocus Server

2) The generated COBOL Service Module is instantiated and invokes existingtransactions that satisfy the business request.

• The 3270-based transactions are accessed using the 3270 Bridge built intoMicro Focus Server.

• COMMAREA-based transactions are invoked via regular program calls.

3) Once existing the transactions have completed, the results (success or failure) aremarshalled back via the request handlers to the service component.

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

Page 21: Extending COBOL to SOA, Web Services and Beyond - A Look at the Architecture

19

A Solution that Benefits the EnterpriseMicro Focus Server delivers a high performance solution for extending existingCOBOL applications with services supporting SOA best practices and adhering toestablished industry standards. Using Micro Focus products allow you to take astrategic 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 supportstandard SOA implementations.

• Instead of using the mainframe for analysis, generation, compilation,debugging and unit testing activities, developers can utilize theworkstation for these activities, thereby reducing costly mainframe cycles.

• Developers can use state-of-the-art workstation based user interfaces toimprove their productivity in creating applications.

• Infrastructure, language protocols and complexities are hidden fromdevelopers, enabling them to focus on delivering business services quicklyrather than debugging code and communication errors.

• Re-usable services supporting loosely-coupled applications deliverunprecedented 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 mainframetechnology, with no code changes, consolidating the investment in provencode.

• Low risk approach to leveraging existing investment in business processingleads to a more efficient development process.

• Rapid development meets business requirements more quickly and at alower cost, while also improving customer satisfaction and loyalty.

• Ready to meet future business challenges head-on with a flexible andadaptable supporting architecture.

Page 22: Extending COBOL to SOA, Web Services and Beyond - A Look at the Architecture

20

Summary

All too often in the mad rush to explore the ‘next big thing’ in softwaretechnology, businesses often forget the huge investment they already have intheir existing assets on the mainframe. These assets have been proven, often overmany years, or even decades, performing the business functions that they weredesigned for. By leveraging the existing mainframe assets, together with theflexibility of moving to a service-based architecture, significant cost savings will berealized.

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

As it is becoming more obvious to corporate visionaries, service orientation ofexisting legacy assets is going to be a key differentiator for successful businesses inthe coming years. The fact that this revolution will be underpinned by the COBOLlanguage and related mainframe technology is a reflection of the importance thatCOBOL has played within business systems over the past decades.

Author: Darren Self, Web Services Evangelist at Micro Focus

September 2006

Page 23: Extending COBOL to SOA, Web Services and Beyond - A Look at the Architecture

21

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

Page 24: Extending COBOL to SOA, Web Services and Beyond - A Look at the Architecture

22

Micro Focus

Micro Focus - Unlocking the Value of Legacy™

Micro Focus is a leading provider of legacydevelopment and deployment software forenterprise platforms. Micro Focus enablesorganizations to reduce costs and increase agilitywith minimal risk by reusing their legacyapplications with contemporary architectures andWeb services. Founded in 1976, Micro Focus is aglobal company with principal offices in theUnited Kingdom, United States, Germany andJapan. For more information, visitwww . microfocus.com .

Micro Focus WorldwideAustralia ............................ 1800 632 626Austria ............................... 0800 293 535Belgium ............................... 0800 11 282Canada............................... 905 824 7397France ................................ 0800 835 135Germany.......................... 0800 182 5443Italy ...................................... 800 784 420Japan............................... 81 3 5793 8550Luxembourg........................... 800 23743Netherlands..................... 0800 022 8562Norway ............................ 47 22 91 07 20Switzerland ....................... 0800 564 247United Kingdom ............ 0800 328 4967United States..................... 877 772 4450Other Countries .............. 44 1635 32646

© 2006 Micro Focus. All Rights Reserved.Micro Focus, Net Express and Revolve areregistered trademarks, and Mainframe Express,Micro Focus Server and Unlocking the Value ofLegacy are trademarks of Micro Focus. Othertrademarks are the property of their respectiveowners.

WPSTWS1006-US