2002 exchange progress worldwide session c10: modernizing your applications john sadd, engineering...

2002ExchangePROGRESS WORLDWIDE

Session C10:Modernizing Your Applications

John Sadd, Engineering Fellowthe Progress Company

© 2002, Progress Software CorporationExchange 2002, Chicago, IL, USA 2

2002Exchange

PROGRESS WORLDWIDE

Goals for this sessionGoals for this session

Think about…– changes in the Progress® language and

tools

– the requirements of today’s application market

– the state of your database and application

– techniques for taking advantage of today’s Progress language and tools


2002Exchange

PROGRESS WORLDWIDE

AgendaAgenda

What’s a “modern” application?

Database design

Separating UI from Logic

Factoring out common code

Migrating existing applications

How Progress Dynamics™ supports these goals


2002Exchange

PROGRESS WORLDWIDEFirst, what’s a “Traditional” Progress application?First, what’s a “Traditional” Progress application?

Character-based– Looks the same on any platform– Or GUI client-server

Host-based or client-server– Always a direct database connection

Built with the 4GL and Progress DB– Limited DataServers, no external interfaces

Static data references in the 4GL– Tables and fields resolved at compile time– Include files or preprocessors for “reuse”


2002Exchange

PROGRESS WORLDWIDESo what are the “Modern” application requirements?So what are the “Modern” application requirements?

Graphical interface– Windows and/or Web UI

Distributed application– Remote clients

– More extensive security requirements More databases and interfaces

– DataServers

– Integration with reporting and other tools Dynamic 4GL table and field references Variety of languages, design tools,

connectivity


2002Exchange

PROGRESS WORLDWIDEHow has Progress evolved to meet these requirements?How has Progress evolved to meet these requirements?

Progress RDBMS-Personal

-Workgroup-Enterprise

DataServer Oracle

WebClient

WebSpeed Browser

Client

WebSpeed Transaction

Server

AppServerGUI Client

Open Clients

Load

Bal

ance

r

Dynamics Framework

Character Client

SQLServer

ODBC

MANAGERS:Connection

SessionProfile

SecurityLocalizationN

ame

Ser

ver

ESQL/C

SQL-92

PDA Wireless

Application Business

Components:Smart Business ObjSmart B2B Object

Dynamic SDO4GL

Sonic

SQL

4GL

DataServer

DataServer

Progress 4GL ADM

Sonic MQ Adapter

Legacy Applications

Custom or Packaged

Applications

Progress or Non-Progress Applications

Webspeed Messenger

AppServer Internet Adapter

APIsTCP/IP

TCP/IP

TCP/IP

HTTP/S

HTTPHTTPS

XML, ProxyGen orSonic MQ

Repository Database

Sonic MQ Server

EJB Server

Any Client

Any Business

Any Data Source

Any Application

Non

-Eng

lish

Sup

port

Progress

Non-Progress


2002Exchange

PROGRESS WORLDWIDEWhat are the central problems for new applications?What are the central problems for new applications?

The world is more complex Existing older Progress apps may not be

adapted to new requirements– Too monolithic, inflexible

– Assume client availability of DB

– Don’t allow for changes to User Interface


2002Exchange

PROGRESS WORLDWIDE

AgendaAgenda


Database design






2002Exchange

PROGRESS WORLDWIDESpecial Progress database and schema characteristicsSpecial Progress database and schema characteristics

Arrays Validation logic defined in the schema “Database” trigger procedures Special data-related language constructs

– Complex nested logic for data retrieval

– CAN-FIND

– FIND NEXT with different indexes

– SHARE-LOCK and EXCLUSIVE-LOCK


2002Exchange

PROGRESS WORLDWIDE

Arrays vs. joins -- IssuesArrays vs. joins -- Issues

SQL Access Open client Indexing Client display

SalesRep RepName Quota[1]

Quota[2]

Quota[3]

Quota[4]

SalesRep RepName Quota

Quota

Quota

Quota

SalesRep

SalesRep

SalesRep

SalesRep

Month

Month

Month

Monthjoined table

array


2002Exchange

PROGRESS WORLDWIDE

Validation Logic -- IssuesValidation Logic -- Issues

Compiled into UI Requires local DB No external access

ON LEAVE…IF CAN-FIND…

Client GUI Session AppServer Session

?


2002Exchange

PROGRESS WORLDWIDE

Trigger Procedures -- IssuesTrigger Procedures -- Issues Execute on client in C/S

(expensive) No UI on Server for

MESSAGEs Often hold real

Business Logic

ASSIGN …


IF <B.L.> THENMESSAGE…Trigger ON WRITE…


2002Exchange

PROGRESS WORLDWIDEComplex navigation logic -- IssuesComplex navigation logic -- Issues

Doesn’t map to queries Poor SQL access Hard in distributed apps

FOR EACH … WHERE … : IF codefld = ‘A’ THEN FIND … WHERE … ELSE IF codefld = ‘B’ THEN… DO I = 1 to 12: IF arrayfld[I] = … THEN…END.

SQL?

SDOs?

queries?

distributed?


2002Exchange

PROGRESS WORLDWIDE

Record Locking -- IssuesRecord Locking -- Issues

SHARE-LOCK and SQL No locks across

AppServer boundary

DO TRANSACTION:FIND … EXCLUSIVE-LOCK.END.

Client GUI Session AppServer Session!


2002Exchange

PROGRESS WORLDWIDETradeoffs in database design and application migrationTradeoffs in database design and application migration

Some Progress “traditions” need to be sacrificed or rethought

How bad is your existing database design?

How much existing business logic can you realistically reuse?

Balance DB schema changes against resulting changes to “salvaged” code

Consider third-party DB access as well as your direct application needs

There’s no single right answer


2002Exchange

PROGRESS WORLDWIDE

AgendaAgenda


Database design






2002Exchange

PROGRESS WORLDWIDEBasic principles of a modern distributed applicationBasic principles of a modern distributed application

Assume NO client database access Plan to reuse business logic Anticipate customization Your “client” and “server” will be different

sessions Allow for non-Progress clients


2002Exchange

PROGRESS WORLDWIDENo client database access means…No client database access means…

No CAN-FIND Less immediate

feedback Minimize client B.L. Minimize

AppServer hits

CAN-FIND …


DB lookup…


2002Exchange

PROGRESS WORLDWIDE

Reusing Business Logic means…Reusing Business Logic means… Encapsulate B.L. Break logic down Separate out complex B.L. Make no assumptions Avoid prompts / UI in B.L.

RUN PricingProcIn AShandle


Order Maint.

Pricingpolicy

Submit orderA

PI

API

API


2002Exchange

PROGRESS WORLDWIDEPlanning for customization means…Planning for customization means…

Allow for translation Define levels of customization Associate security with UI Define customization hooks Store customization dataLabel:

Label:

Label:

Label:

Menu/texttranslation

Data translation

Security User preferences

Customizationdata

Customizationmanager


2002Exchange

PROGRESS WORLDWIDEClient and server in different sessions means…Client and server in different sessions means…

No shared variables Clean interface No hierarchy Use a property API

Clientproc1


Get property

Pricingpolicy

Submit orderA

PI

API

API

Clientproc2

Mainproc


2002Exchange

PROGRESS WORLDWIDEAllowing for non-Progress clients means…Allowing for non-Progress clients means…

Provide alternatives to Progress API

Consider XML Design your API to

allow for this

Client Session AppServer Session

Order Maint.

Pricingpolicy

Submit orderA

PI

API

API

XML


2002Exchange

PROGRESS WORLDWIDE

How bad is my old code?How bad is my old code?

Monolithic “spaghetti” code is the bane of any migration plan

BUT, things may not be as bad as you think:– Much of that old code may be repetitious

– Patterns provide clues for cleanup

– Much “business logic” in the UI is just routine client support

– A standard framework can replace huge amounts of old client-side code


2002Exchange

PROGRESS WORLDWIDE

AgendaAgenda


Database design






2002Exchange

PROGRESS WORLDWIDE“Traditional” Progress constructs for code reuse“Traditional” Progress constructs for code reuse

Include files with parameters Preprocessor values Code generators These were all great, BUT the result is:

– Proliferation of source procedures

– Proliferation of compiled code

– Maintenance headaches

– Migration problems

– More code to deploy and keep track of


2002Exchange

PROGRESS WORLDWIDE

Dynamic 4GL features can helpDynamic 4GL features can help Dynamic widgets Dynamic buffers, queries, and temp-tables Dynamic function call syntax Dynamic CALL syntax (in 9.1D) Use these newer constructs to:

– Write a single procedure for an operation on any table or query

– Build single procedures for comments, auditing, and other common requirements

– Minimize both source procedures and r-code


2002Exchange

PROGRESS WORLDWIDE

“Modern” Progress procedures“Modern” Progress procedures

Not top-down Use persistent procedures as

libraries Use super procedures for

inheritance Eliminate redundant procedures Store the “parameters” for them

Persistentprocedure

library

Super Procedure

“class”

Applicationcode

Procedureparameters

RUNIN…

Inherit

Parameterize


2002Exchange

PROGRESS WORLDWIDE

AgendaAgenda


Database design






2002Exchange

PROGRESS WORLDWIDESo how do I get from here to there?So how do I get from here to there?

Make essential changes to your database– But don’t do a whole redesign if you have

logic to salvage Devise ways to “wrap” B.L. and reports Be realistic about rethinking your UI

– Your old frames and procedure flow just may not make sense in GUI or on the Web

Balance choices between redesign and salvage– There’s no single right answer


2002Exchange

PROGRESS WORLDWIDEWhen is a rewrite not really a rewrite?When is a rewrite not really a rewrite?

…When you eliminate a lot of redundant code

…When you let a standard framework take care of a lot of the “modernizing” for you

…When you wrap your business logic and reports to be callable in new ways

You may wind up with a very different-looking set of procedures, BUT the essence of your application can be preserved– AND it will be more maintainable, flexible,

Future-Proof™


2002Exchange

PROGRESS WORLDWIDE

AgendaAgenda


Database design






2002Exchange

PROGRESS WORLDWIDEYou don’t have to use Progress Dynamics, but…You don’t have to use Progress Dynamics, but…

Progress Dynamics provides an architecture for distributed applications

UI generation is provided Old code is replaced by standard behavior

– Navigation, Updates, Lookups, etc. Manager utilities provide standard support

– Security, user maintenance, localization, connection management, etc.


2002Exchange

PROGRESS WORLDWIDE

To summarize…To summarize… Assess honestly which parts of your DB

and application can be salvaged– and which will really benefit from redesign

Be realistic about time frames and goals– You won’t rework a major app in a few

months, with or without Dynamics– Balance a step-wise progression against

the benefits of a complete redesign Take advantage of advances in language

and tools Consider the big picture – it’s more than

just Progress


2002Exchange

PROGRESS WORLDWIDE

Goals met?Goals met?

Think about…– changes in the Progress language and

tools

– the requirements of today’s application market

– the state of your database and application

– techniques for taking advantage of today’s Progress language and tools


2002Exchange

PROGRESS WORLDWIDE

Questions

2002 exchange progress worldwide session c10: modernizing your applications john sadd, engineering...

Documents

special progress database

progress dblimited dataservers

database designseparating

data retrievalcanfindfind

gl table

design tools

new applications

new requirementstoo