The Why and How of the imodernize(d) Application Architecture

Transcription

1 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

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

3

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

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

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

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

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

9 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 3 rd 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

10 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

11 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

12 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

13 Program Centric vs Data Centric Most AS/400 Shops Most HLL / OO 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

14 Program Centric vs Data Centric

15 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)

16 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) Mult Files opened HLL Program RLA

17 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)

18 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) HLL Program SQL Mult rows at a time (Large Pipe) Set based processing SQL View Select columns From tables Where condition DBMS Physical Data

19 Current Application Architecture Data (PF, LF) UI Business Logic

20 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!

21

22 Modernization DB2 Database Prior to Modernization RPG PGM I/O Existing LF (Access Path) I/O Physical File

23 Modernization DB2 Database After Modernization RPG PGM I/O Existing LF Access Path From new SQL index I/O SQL Table After creating the new DDL based SQL table(s) Create SQL indexes identical to old LF access paths Create LF named as old PF

24

25

26

27

28

29 Database Reengineering

30 Modernizing IBM i Application Access

31 Modernizing IBM i Application Access

32 Modernizing IBM i Application Access

33 Modernizing IBM i Application Access

34 Modernizing IBM i Application Access

35 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

36 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

37 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

38 THINK An exploration into making the world work better