Integrating CICS applications into SOA Franz Konrad Integrating CICS applications into SOA

Agenda Session Overview: CICS Applications and SOA SOA Options Integrating CICS applications into SOA CICS Applications and SOA SOA Options Transaction Server native options Indirect options Contrasting options to needs

Market Forces - IT Challenges Service Oriented Architecture is maturing Adoption of SOA increasing throughout IT Move to service-enable applications Infrastructure for composition Extend use of applications Legacy applications need to participate Minimize risk Composite Services (Integrated / more business context) Atomic-Level Service Components (Granular)

CICS Applications and SOA CICS applications generally pre-date SOA architectural guidelines Typically CICS applications are monolithic UI and logic have no clear separation Even when separated, use of components are not assumed asynchronous SOA is an architecture that assumes Applications are built from distributed ‘remote’ services Service use is asynchronous Services are composable Application Architeture

SOA Options At a high level Migrate to new architecture (platform) Involves rewrite of application Re-hosting is not a solution to architecture Evolve applications (break them into services) Available with new Transaction Server additions Indirect access through appended infrastructure

Three Evolutionary Options Native technology to current CICS platform Leverage existing CICS tools z Series CICS TS COBOL App TS 3.1 Integrated Web services Extended SOA Network CICS Bridge Exit or UI Access CICS COMMAREA Access

Factors to Consider SOA strategy Skill-sets Mainframe capacity 2 tier versus 3 tier Technology direction Skill-sets Skills for implementation Long-term skill requirements Mainframe capacity Impact to existing infrastructure Impact to existing applications Invasive vs. non-invasive approach

Transaction Server Web Services Native technology to current CICS platform Leverage existing CICS tools CICS TS 3.1 Cobol App Integrated Web services

CICS Integrated Web Services System Programmer Process it with the Web Services Assistant to populate Unix System Service (HFS) files (WSDL & WSBIND) Configure CICS URI Mapping, WebService and Pipeline resource definitions Make the WSDL available to the programmer to build the Web Service client (service Requester) Application Manager Find / Learn app language Structure -- copybook Generate WSBIND and WSDL HFS Config WS Bind WSDL CICS/Web Services Assistance WSDL IDE Tools WS Bind File Language Structure CICS Web Services Generate WSBIND and WSDL files -- Application Manager Create a TCPIPService resource def -- System Programmer Create a PIPELINE resource def and conf file -- sys prog Install TCPIPSERVICE and PIPELINE def –WEBSERVICE and URIMAP defs (auto-created) -- sys prog Publish WSDL -- Sys proge for each Commarea application,   -          Find and understand the correct language structure (copybook) -          Process it with the Web Services Assistant to populate Unix System Service (HFS) files (WSDL & WSBIND). -          Possibly configure CICS URI Mapping, WebService and Pipeline resource definitions. -          make the WSDL available to the programmer to build the Web Service client (service Requester) Each request is XML parsed on the host, converted to EBCDIC, processed by the business logic, converted back to UTF-8 and XML generated. URI Def Pipeline Service Requester Business Logic Conversion CICS TS 3.1

Attributes of Native Approach High availability Available with provider application QoS of CICS extended to services Inherit performance characteristics of platform 2-Tier approach reduces security exposure Extends CICS Skill-sets to service layer

Factors Needs application level interactions Legacy CICS applications may need modifications Logic separate from UI SOAP service needs to be invoked directly Puts processing burden on the mainframe Legacy system provides service Leverages, but necessitates CICS skill-sets For service creation For on-going alignment with business processes Base services built w/ CICS skills, composite services with mid-tier skills

Appropriate Use Good when a standards based approach is desired This direct SOAP approach is open standards based and fully integrated into CICS Transaction Server and uses open standards based This is a useful approach for: Enterprise modernization (legacy modernization) New MF application development needs Business integration in a robust CICS shop Web services implementation Best for new development

Indirect Approach COMMAREA CICS 3270 Bridge support Uses a proxy or gateway to aggregate transactions for use in services Proxy or gateway can reside on or off mainframe, but is a logical middle-tier regardless CICS 3270 Bridge support Uses bridge exits available in recent CICS Transaction Server versions Does not require a middle-tier other than for convenience

COMMAREA Access Gateway or proxy access to API Use of API access to transactions CICS TS Cobol App CICS DPL Access ECI, EXCI, RPC, CWS

CICS DPL Services copybook COPYBOOK Service Operation Host Transaction Design Studio System Programmer Install listener (optional) copybook Application Manager Find / Learn app language structure -- copybook Describe operations for service Create Service Publish Service (WS, EJB, .NET Class…) CICS DPL Access Cobol App IP Listener Generate WSBIND and WSDL files -- Application Manager Create a TCPIPService resource def -- System Programmer Create a PIPELINE resource def and conf file -- sys prog Install TCPIPSERVICE and PIPELINE def –WEBSERVICE and URIMAP defs (auto-created) -- sys prog Publish WSDL -- Sys proge for each Commarea application,   -          Find and understand the correct language structure (copybook) -          Process it with the Web Services Assistant to populate Unix System Service (HFS) files (WSDL & WSBIND). -          Possibly configure CICS URI Mapping, WebService and Pipeline resource definitions. -          make the WSDL available to the programmer to build the Web Service client (service Requester) Each request is XML parsed on the host, converted to EBCDIC, processed by the business logic, converted back to UTF-8 and XML generated. COPYBOOK Service Operation Host Transaction

Attributes of Gateway / Proxy DPL Access Non-invasive to host or application Links to existing transactions Leverage existing APIs (ECI, EXCI,...) High performance characteristics 3-Tier approach Reduces MF processing Transaction service can reside on any platform, Or can reside in zOS, a CICS, or linux region Service can be made native to service consumer: Web service, J2EE, .NET, etc...

Factors with Gateway / Proxy DPL Access Needs transaction level interactions Only works with CICS logic Logic must be separate from UI Loses process logic in UI UI typically contains business processes Need knowledge of the CICS application’s constraints No control over granularity Legacy system provides transaction as base service Orchestration/ BPM assumed for building services with business context

CICS 3270 Bridge Access BMS or terminal access to CICS applications Appended infrastructure within CICS Cobol App CICS 3270 Bridge Client I/F

CICS 3270 Bridge Access CICS TS 2.2 (+) Design Studio Cobol App Bridge Application Manager Learn application  business processes Describe operations for service Create Service Publish Service (WS, EJB, .NET Class…) System Programmer Install Verastream Bridge Engine Mid-Tier Admin Load Client Interface on Server Design Studio TCP/IP Cobol App CICS TS 2.2 (+) Bridge Engine Client I/F

Attributes with CICS 3270 Bridge High availability Available with provider application Inherit performance characteristics of platform 2-Tier approach reduces security exposure Abstracts CICS Skill-sets from service layer Has access to full CICS application details BMS maps, terminal controls, invoked transactions Retains process logic embedded in UI Full control over granularity (business context) of services

Factors with CICS 3270 Bridge Needs 3270 application UI Does not see stand-alone transactions Works with symbolic names if on BMS map 3270 app must be within CICS May put processing overhead on the mainframe CICS region provides service Removes VTAM from process overhead 'This can be a net benefit'

Appropriate Use Transactions are not separate from UI Useful approach for: Enterprise modernization (legacy modernization) Integration projects that need CICS application use Web services implementation Best when tight integration needs are combined with low CICS skill requirements This is a non-invasive application approach that uses a CICS resident access method Services are typically built with only terminal or systems analyst application level knowledge

General Mainframe Integration Encapsulate data and logic via the screen interface (UI Data Stream) Supported Interfaces: 3270 VT420 AS/400 HP700/92 HP2392A

CICS Options Summary Useful for new development Great for logic mixed with UI Low impact to host and host application z Series CICS TS COBOL App TS 3.1 Integrated Web services Extended SOA Network CICS Bridge Exit or UI Access CICS COMMAREA Access

Transaction Integrator Summary Access Low Host Skills Low Host impact Mixed Logic 2-Tier Products TS Web Services x COMMAREA access Bridge Access General Access Transaction Integrator Bridge Integrator Host Integrator