Transcript The Why and How of the iModernize(d) Application Architecture

The Why and How of the
iModernize(d) Application
Architecture
David Andruchuk
Sr. Architect
Computer Systems Design Associates, Inc.
What can i do…..i can do Modernized
IBM i is very different from the other operating systems
in the industry, and the differences are related to its
unique architecture. From the birth of the AS/400, the
goal of the operating system was to create a platform
that would allow a business to be insulated from the
complexity of IT technology.
Our customers want to "run the business, not the
computer."
The five architectural elements below are not just
marketing words -- they are built into millions of lines of
operating system code -- and their purpose is to make
IBM i stable, simple, secure and scalable.
DB2 for i & Single Level Store: We build intelligence
and expertise into our handling of customer data. DB2
on IBM i is a part of the operating system, and it
automates many functions that require human analysis
and management on other operating systems. Single
Level Store is a way of treating all storage attached to
IBM i as if it is one huge set of memory. Working with
DB2, our storage management spreads data across a
customer's DASD in order to optimize data access. For
these two reasons, customers rarely have to hire
storage administrators or database administrators for
their IBM i environments, and those professionals who
are hired spend more time on analysis than on day-today management.
Object-Based Architecture: AS/400 was built
understanding that security would be a key requirement
of all businesses. Each object on IBM i has a set of
well-defined functions, and it is architecturally
impossible to treat an object in a way that violates its
intended use. For example, two common methods of
spreading viruses or “Trojan Horses” in other operating
systems are to modify code in a compiled executable,
or to rename an object so that a program looks like
something that is not dangerous -- sending a program
in an e-mail but making it appear to be a photo, for
example. Neither of these two attacks can be done to
software compiled as IBM i programs, because those
operations are simply not allowed by the architecture.
Integration: We believe that the only software a typical
customer really wants to deal with is the software that
runs its business directly -- the applications that are
developed by the customer or that they buy from our
ISVs. For that reason, our operating system comes
integrated with all of the necessary "middleware" a
business application might need: Not only DB2, but also
web servers, security services, user identity
management and so on. These pieces of middleware
must be added on top of other operating systems. We
incorporate them into IBM i, and we ensure they fit into
the architecture of the system, including the objectbased architecture, as well as the virtualization and
TIMI.
Work Management: The AS/400 was built assuming that a
business would rather have one physical system that is
capable of running all of the workloads it needs, rather than
buying a new system for each workload. To support that
idea, IBM i has a "subsystem" concept that allows an ERP
application to sit next to a CRM application, which sits next
to a web server and so on -- all of them sharing resources
such as the database, but not colliding with one another.
This is very different from typical competing operating
systems, where it is architecturally difficult to run multiple
workloads safely on one machine -- or one virtual machine - and so the industry has had tremendous "sprawl" as
customers of other platforms have had to buy a new system
for each application or workload. Yes, today these other
operating systems “solve” the problem their architectures
created with virtualization. Subsystems are a virtualization
technology that existed since the beginning of the operating
system, and they allow an IBM i client to spend less on
managing multiple environments.
Technology Independent Machine Interface: IBM i
is split into two pieces, and the TIMI separates them.
The TIMI also provides a layer of abstraction that
does two important things. First, it allows programs
that were compiled on older releases to run
unchanged -- without even recompiling -- as IBM i
changes technology beneath those applications. The
operating system moved from a 48-bit CISC
hardware architecture to today's Power architecture
without the need for customers to recompile code.
Second, the TIMI works together with some of the
IBM i-specific capabilities built into POWER
processors to keep system memory separate from
user memory, protecting the operating system from
intentional or unintentional interference. An
interesting point though, is that all of the IBM i
"device drivers" for I/O are beneath this TIMI. To
protect the integrity of the operating system, and by
extension the customer’s data, IBM i cannot have a
"device driver" authored by another provider.
The Why of the iModernize(d) Application Architecture
SQL adoption on the IBM i has lagged for the past 10 years
Yet it was one of the first platforms to be 100% ANSI 2008 SQL compliant
Standards Compliancy
SQL is portable and widely accepted
Openness
Allow access to your DB to 3rd party products
Performance
64K path versus an 8-32K path using SQE versus CQE
Skills
SQL skills are readily available and transferable
Functionality
Large object data types, Encryption, Identity columns, etc..
Data Integrity
Constraints, Referential Integrity, etc.. for all DB access
The Why of the iModernize(d) Application Architecture
The greatest strengths of IBM i have caused its greatest weakness
Applications keep running despite changes to the processor and database
Business needs are not being met using DDS and RLA
This can risk applications and data being moved to another system
Data Encryption
Protect sensitive data using AES, RC2 or TDES (Triple DES) encryption
Goals of the iModernize(d) Application Architecture
Drive as much work down into the database management system as
possible to gain consistency for all application platforms.
Define business rules as part of the database to gain flexibility and rules
applied to all interfaces
Take advantage of SQL only capabilities to gain performance and
modification of the database without affecting programs
Database evolves to gain expandability to meet new business
requirements and new technologies
The ROI of the iModernize(d) Application Architecture
Faster IT response to business requirements
Reduced software development and maintenance costs
More reliable data to run our business on
Improved performance and scalability
Sensitive data protection and referential integrity
Better documentation and data modeling tools
Access to larger pool of talented developers
Program Centric vs Data Centric
Most HLL / OO Shops
Most AS/400 Shops
Program Centric
•
•
•
•
•
•
•
Traditional RLA I/O based
Slows Down as # of rows increase
Less Efficient
Less Flexible
Program(ers) Determine Access
Method of Data
Single Layer Architecture
Row Based Data Access
Data Centric
•
•
•
•
•
•
•
SQL I/O Based
Speeds up as # of rows increase
Very Efficient
Very Flexible to Changing Business
Database Determines Access Method of
Data
Multi Layer Architecture
Set Based Data Access
Program Centric vs Data Centric
Program Centric Architecture
OPTIONAL - Business / Data Layer
(Service Programs or Stored Procedures
attached to Data)
U/I Data Layer
(Green Screen programs attached to
Data)
Program Centric Architecture
•
•
•
•
Slower Processing
Larger Application (more lines of code)
DBMS resources are not doing much work
Inconsistent results (business rules in each program)
1 row at a time
(Small Pipe)
HLL Program RLA
Mult Files opened
Data Centric Architecture
UI – User Interface Layer
(RPG / HLL UI)
Business Logic Layer
(Service Programs)
Data Access Layer
(Stored Procedures)
Logical Data Layer
(Views)
Physical Data Layer
(Tables / Indexes)
Data Centric Architecture
•
•
•
•
Faster Processing
Smaller Application (less lines of code)
DBMS resources are doing lots of work for you
Consistent Results (business rules in DBMS)
DBMS
Physical Data
SQL View
Mult rows at a time
(Large Pipe)
Set based processing
Select columns
From tables
Where condition
HLL Program SQL
Current Application Architecture
Data
(PF, LF)
UI
Business Logic
The How of the iModernize(d) Application Architecture
Application modernization happens on three levels
The database, the development environment and the user interface
DDS to SQL DDL Reverse Engineering
Converting our source for recompilation
Migrating the database
Create SQL Tables, Indexes and Views
Isolating the database
Create I/O access via Stored Procedures external to our applications
Enhancing the database
Adding Referential Integrity, moving business rules to the DB
25 Years to create our databases
this will not be changed overnight...if it was that easy, we’d be done!
Modernization DB2 Database – Prior to Modernization
RPG PGM
I/O
Existing
LF
(Access
Path)
I/O
Physical
File
Modernization DB2 Database – After Modernization
RPG PGM
I/O
Existing
LF
After creating the new DDL based SQL table(s)
• Create SQL indexes identical to old LF access paths
• Create LF named as old PF
Access
Path
From new
SQL index
I/O
SQL Table
Database Reengineering
Modernizing IBM i Application Access
Modernizing IBM i Application Access
Modernizing IBM i Application Access
Modernizing IBM i Application Access
Modernizing IBM i Application Access
Real Life Examples
Business Analyst complaining about query taking too much time.
Prior to Performance Tuning
• Table had a LF by datefield and zip
• Query took 25 minutes to run on 100 million rows
Suggested Performance Tuning
• Create an EVI index by datefield
After Performance Tuning
• Query took 1minute 45 seconds to run on 100 million rows
Real Life Examples
Need to add and expand columns to an existing table
Requirements:
•
Input Primary RPG program
•
IP File is Join LF with Select / Omit (Dynamic Selection)
•
Implemented Level Breaks
•
Users complaining that it was taking too long to run
Solution:
•
Create VIEW with same fields as Join LF
•
Define cursor in one time section of program
•
Fetch from cursor at each cycle
•
Look for field value changes for Level Breaks
•
Total development time was 30 minutes including testing
•
Run time went from 27 minutes to 2 minutes
Real Life Examples
Need to add and expand columns to an existing table
Requirements:
• Expand Name and Address columns in our marketing table in order to account for
longer data for our business.
• Add new language preference column in our contact table to support web.
Issue:
How do we do this with out modifying and recompiling 100s of programs?
Solution:
ALTER TABLE CONTACTS ALTER COLUMN ADDRESS_LINE1
SET DATA TYPE CHAR (50 ) CCSID 37 NOT NULL
ALTER TABLE CONTACTS
ADD COLUMN LANGPRF CHAR(5)
You only have to change/recompile the Applications that need the new column OR
that need the expanded column size as there is no Format Level ID change
THINK
An exploration into making the world work better