Automating Application

Development for Legacy

IT Systems with SOA &
MDA

Framework & Code Generator

By Dr. Chung-Yeung Pang, Seveco AG, Switzerland
pang@seveco.com
www.seveco.com
Situation in IT
 Programming Languages:
 ~3 million COBOL programmers.
 ~1.6 million VB programmers.
 ~1.1 million C/C++ programmers.

 Most mission critical applications have been written in COBOL.

 The dependency on the interfaces, performance, transaction scopes
prohibits the change and mixing of other programming languages.
 IBM reported the usage of zSeries mainframes grew 28% year-to-
year in 2005.
 The COBOL Center publishes:
 Investment in COBOL expected to be over $1.5 Trillion.
 Number of transaction in COBOL > hits on the Internet.
Experience (1)
 1998
 Experience with CORBA IDL drove us to move from fixed record remote
procedure call style messaging to document-style messaging with XML
and took a step into Service Oriented Architecture (SOA).
 2000
 Facing problems with interoperability between old and new platforms led
to the development of SOA in legacy IT environment and COBOL XML
framework.
 2003
 First code generator for Data Object Descriptors for marshalling and
unmarshalling of XML structure from / into COBOL data structure based
on class diagrams.
Experience (2)
 2004
 Introduced Model Driven Architecture (MDA) techniques into business
service development.
 Developed a context based centralized service process controller
service architecture that allows plug and play of business components.
 2005
 Leveraged SOA and MDA in multiple projects.
 2006
 Developed service and unit test automation using MDA approach.
 Developed high level platform independent modelling and generation of
platform dependent code such as PL1 and Java.
 Developed frameworks for integrating existing applications written in
different languages into SOA.
Experience (3)

 Success in 8 IT projects
 Treasury Products, Credit, Payments, and Securities.
 Project size: 10-30 team members.
Achievement
 Turned failure projects to success.
 From
 Undocumented systems
 Ad-hoc software development style
 Low productivity
 Error prone
 Inflexible for code adaptation to standards
 Low/no reusability
 Require experienced programmers for the development
 To
 Documented systems with modelling
 Architect & Analyst driven development
 High productivity
 Minimum error
 Flexible code adaptation to standards
 High reusability
 Automation through the use of models and effectively reduce the number of
experienced programmers for the development
Traditional Modular Architecture
 Strong coupling of
modules with no central
control of business logic.
 Difficult to test individual Service Interface

modules. A
 Does not allow plug and
play of modules.
 Difficult to enhance and B C

maintain.
 Silo or monolithic D E F G H
approach to solving
business requirements.
Component Based Service
Oriented Architecture
Mainframe

Adaptor
Existing Program

Service Process
Controller

Adaptor
Existing Program

XML
Service Mediator

Service Component
Context Container
(IDOM)

Service Component
Framework
 XML Handling Facilities in COBOL, PL1, C++, Java
 XML parser for transformation of XML messages into integrated document object
model IDOM.
 Marshalling and Unmarshalling Data Object structure to and from XML tree
structure using meta-information from Service Data Object Descriptors (SDOD).
 XPath support.
 Service Mediator
 Control transaction.
 Handle service messages.
 Set up the context container.
 Resolve and instantiate service process controller.
 Context Container (IDOM)
 Contains service context in a document style tree structure in an Integration
Document Object Model.
 Provides API to insert and extract data from the service context as well as
navigation of the context tree.
 Service Process Controller
 A finite state machine that performs the centralized process control based on
Service Process Control Descriptor (SPCD) with state, event and transition.
 Message Interface Modelling and
Generation
 Message Interface Modelling (MIM) and SDOD generation based
on class diagrams

Data Structure
of Existing
Program (e.g.
COBOL Copy
Book)

Optional

SDOD in COBOL/ PL1/ Java/ C

Customer Address

id : txt32 street : txt32

XML/DTD/XSD 1 1 streetNo : n4
name : txt32
firstName : txt32 city : txt32
Data Object (COBOL Copy Book/ cityCode : n9
PL1 Structure/ Java Class/ C country : txt32
Header File)
Service Message and Context
Design Customer Address

id : txt32 street : txt32

1 1 streetNo : n4
name : txt32
firstName : txt32 city : txt32
cityCode : n9
country : txt32
1

*
Account

no : txt32
type : txt32
balance : amount
infoText : txt256

Bank Account
Custody Account FX Account
interestRate : n3

1
1 1

XML/DTD/XSD Saving Account

*
*
Trade Movement
Current Account FX Trade Movement
buySellCode : txt1 *
buySellCode : txt1
stockId : txt32 Deposit Withdraw Movement
currency : currencyCode
stockName : txt32
depositWithdrawCode : txt1 transactionRate : amount
price : amount
currencyAmount : amount
totalStock : n9

Movement

transId : txt32
mDate : date
type : txt32
mAmount : amount
infoText : txt256
 Service Process Control Descriptor
Design and Generation
 SPCD design and generation from
Customer Asset View Request
state model.
«Process State »
Customer Info Processing

Service
Get Customer Info

Customer Info Retrieved

«Process State »
Account Info Processing

Service
Get Customer Account Info

[Control Stack Empty]

Custody Account Info Retrieved Account Info Retrieved FX Account Info Retrieved

«Process State » «Process State » «Process State »

Custody Account Position Keeping Processing Normal Account Position Keeping Processing FX Account Position Keeping Processing

Service Service Service

Get Custody Account Movements Get Account Movements Get FX Account Movements

Custody Account FX Account Movements

Movements Retrieved Account Movements Retrieved
Retrieved
 Service Component Modelling and
Generation Frame and pattern based modelling and
«SOAF Start Class»
CustomerInfo
1 «reference» 1 Customer Adaptor

«Procedure»
«Procedure»
initializeAdaptor ()
createDataObject ()
up to 100% code generation.
W-Parm «Procedure» getCustomerID ()
1 1 01 IDOM-Data.
«Procedure» callCustomerInfo ()
COPY FWPC 0000.
CustomerID : txt32 «Procedure» setEvent ()
«Procedure» setLogicalRef () 01 W-Parm.
05 CustomerID PIC X (32).

LINKAGE SECTION .
Module Pattern *+---+---+---+---+---+---+---------- +---------------------------- *
01 CustomerInfo .
COPY CUSTINFO .

01 PC-Data.
Error Sequence Frame COPY FWPC 0000.

«Procedure» «Code Pattern» *---------------------------------------------------------------- *

initializeAdaptor PROCEDURE DIVISION USING PC -Data
InitActionChain
.
*+---+---+---+---+---+---+---------- +---------------------------- *
MAIN SECTION .
DOD="Customer Info"
DataObject=CustomerInfo «Code Pattern» PERFORM initializeAdaptor
«Procedure»
IF Status -Error THEN
createDataObject CreateDataObject
PERFORM Handle -Error
GO TO Return -Point
END -IF
XPath="./Customer[@ID]" PERFORM createDataObject
«Procedure» Attribute=CustomerID «Code Pattern» IF Status -Error THEN
getCustomerID PERFORM Handle -Error
GetAttributeFromIDOM
GO TO Return -Point
END -IF
Object=CUSTINFO PERFORM getCustomerID
IF Status -Error THEN
«Procedure» Parameters="CustomerID, CustomerInfo" «Code Pattern» PERFORM Handle -Error
callCustomerInfo CallObject GO TO Return -Point
END -IF
PERFORM callCustomerInfo
IF Status -Error THEN
«Procedure» Event="Customer Info Retrieved" «Code Pattern» PERFORM Handle -Error
setEvent GO TO Return -Point
SetEvent END -IF

LogicalName="Customer ID"
«Procedure» Reference=CustomerID «Code Pattern»
setLogicalRef SetLogicalRef
Test Automation (1)
 Test data has XML format and structure is generated from class
model.
 Direct testing for business services with XML messages.
 Test service components or any existing applications with test
modules generation.

1 generates 1 Test Data Structure 1 fill in for 1..* Test Data

Interface Class

*
«use»
1 Test Case Model
«use»
1 1
* generates
Test Module
generates * Test XML
mapXMLToDataStructure ()
callApplModule ()
renderOutputXMLFromDataStructure ()
Test Automation (2)
 Use of SOA for testing.
Case Tool Host System

Test Case Model Test Service Mediator

Test XML Message
1
activates
*
Test Module

mapXMLToDataStructure ()
callApplModule ()
renderOutputXMLFromDataStructure ()
1

calls
1
Application Module
 Trade Sequence Test Case VBS Pattern

Variable-Name=aFiles
«Code Segment» Variable-Value="""" & Directory & "TR.xml", """" & Directory & "TB.XML", """" & Directory
«Code Pattern»& "TC.xml"
Define_Files «Use Pattern» Define-Variables

Test Automation (3)

File-Name="""" & Directory & "TB.xml"
XPath="//transactionRef"
Check-XPath="//ids/system/systemID"
Check-Value="ABACUS"
«Code Segment» Return=abacus_id «Code Pattern»
Fetch_Abacus_Id «Use Pattern» Get-XML-Value-With-Check

Variable-Name=abacus_id
 Modelling test process using «Code Segment»
Update_Abacus_Id
With-Value=+1 «Code Pattern»
Calculate-Value

class and activity diagram. For

File-Name=fileName
XPath="//transactionRef"

 Generate test scripts in VB or [Each fileName in files] Value=abacus_id

Check-XPath="//ids/system/systemID"
«Code Segment» Check-Value="ABACUS" «Code Pattern»

Java Script for test process. Set-Abacus_Id «Use Pattern» Set-XML-Value-With-Check

 Execute test scripts direct from For

modelling tool or from a batch file. [Each fileName in files]

«Code Segment»
User-Name=User-Name
File-Name=fileName
Output=testResult «Code Pattern»
Do_Test «Use Pattern» Execute-Test-From-File
Stream=testResult
XPath="//Status@Result"
«Code Segment» Return=status «Code Pattern»
Get_Status «Use Pattern» Get-XML-Value-From-Stream

«Action Module» «Code Segment» Entry-Value="File Name: ", fileName, " Status: ", status} «Code Pattern»
Test-Case-One «Action Module»
Log_Status «Use Pattern» Add-Log-Entry
Yeung Test Case One:Test-Case-One::Test-Case-One
User-Name User-Name = yeung
Directory Directory = C:\TestData\Yeung
Library-Directory = S:\Test Automation Demo\Library\ Library-Directory = S:\Test Automation Demo\Library\
If
«Action Module Constructor» Test-Case-One ()
[status = 'Exception']
File-Name="exception.xml"
«Code Segment» Value=output «Code Pattern»
Write_Output «Use Pattern» Write-String-To-File

File-Name="exception.xml"
«Code Segment» Application-Name="notepad" «Code Pattern»
Test Script Display_Output «Use Pattern» Display-File-In-Application

«Code Segment»
Exit_For

Joint

«Code Segment» Message-Text="Test process successfully completed!" «Code Pattern»

Display_Complete «Use Pattern» Display-Message
Benefits
 Best practices.
 Well documented system.
 Plug & play SOA.
 Simplify testing and integration.
 Maximize reuse.
 Increase business and IT agility.
 Leveraging what already exists and add
functionality as required.
 Scalable development.
 Resource sharing across organization
using repository based (ARTISAN)
modelling tool.
 Reduce development & maintenance
cost.
 Traceable from requirements to the
code.
Demo
 Model Definition
 Code Generation