Integrating CICS into SOA

Download Report

Transcript Integrating CICS into SOA

Franz Konrad
Integrating CICS applications into SOA
Agenda
Session Overview:
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
Composite Services
– Extend use of applications (Integrated / more
business context)
• Legacy applications need
to participate
– Minimize risk
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
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
CICS
Bridge Exit or
UI Access
CICS
COMMAREA
Access
Extended
SOA
Network
Factors to Consider
• SOA strategy
– 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
Application Manager
• 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)
Find / Learn app language Structure -- copybook
Generate WSBIND and WSDL
WSDL
CICS/Web Services
Assistance
IDE Tools
HFS
Config
WS Bind
Language
Structure
File
CICS Web Services
URI
Def
WS Bind
WSDL
Business Logic
Conversion
Pipeline
CICS TS 3.1
Service
Requester
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
– 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
System Programmer
Design Studio
• Install listener (optional)
Application Manager
• Find / Learn app language structure -- copybook
• Describe operations for service
• Create Service
• Publish Service (WS, EJB, .NET Class…)
Cobol App
copybook
IP
Listener
CICS
DPL Access
Service
Operation
COPYBOOK
Host Transaction
Attributes of Gateway / Proxy
• Non-invasive to host or application
– Links to existing transactions
– Leverage existing APIs (ECI, EXCI,...)
DPL
Access
• 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
• Needs transaction level interactions
– Only works with CICS logic
– Logic must be separate from UI
DPL
Access
• 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
Application
Manager
System Programmer
•• Learn
application
business
processes
Install Verastream
Bridge
Engine
•Mid-Tier
Describe
operations
for
service
Admin
•• Create
Service
Load Client
Interface on Server
• Publish Service (WS, EJB, .NET Class…)
Design Studio
CICS TS 2.2 (+)
Cobol App
Bridge
Engine
Client
I/F
TCP/IP
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
CICS
Bridge Exit or
UI Access
CICS
COMMAREA
Access
Extended
SOA
Network
Summary
Access
Low
Host
Skills
ls
Low
Host
impact
Mixed
Logic
TS Web Services
Services
2-Tier
Tier
Products
x
COMMAREA
access
x
x
Bridge Access
x
x
x
General Access
x
x
x
Transaction
Integrator
x
Bridge
Integrator
Host Integrator