2002 exchange progress worldwide session c10: modernizing your applications john sadd, engineering...
Post on 02-Jan-2016
226 Views
Preview:
TRANSCRIPT
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
© 2002, Progress Software CorporationExchange 2002, Chicago, IL, USA 3
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
© 2002, Progress Software CorporationExchange 2002, Chicago, IL, USA 4
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”
© 2002, Progress Software CorporationExchange 2002, Chicago, IL, USA 5
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
© 2002, Progress Software CorporationExchange 2002, Chicago, IL, USA 6
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
© 2002, Progress Software CorporationExchange 2002, Chicago, IL, USA 7
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
© 2002, Progress Software CorporationExchange 2002, Chicago, IL, USA 8
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
© 2002, Progress Software CorporationExchange 2002, Chicago, IL, USA 9
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
© 2002, Progress Software CorporationExchange 2002, Chicago, IL, USA 10
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
© 2002, Progress Software CorporationExchange 2002, Chicago, IL, USA 11
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
?
© 2002, Progress Software CorporationExchange 2002, Chicago, IL, USA 12
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 …
Client GUI Session AppServer Session
IF <B.L.> THENMESSAGE…Trigger ON WRITE…
© 2002, Progress Software CorporationExchange 2002, Chicago, IL, USA 13
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?
© 2002, Progress Software CorporationExchange 2002, Chicago, IL, USA 14
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!
© 2002, Progress Software CorporationExchange 2002, Chicago, IL, USA 15
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
© 2002, Progress Software CorporationExchange 2002, Chicago, IL, USA 16
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
© 2002, Progress Software CorporationExchange 2002, Chicago, IL, USA 17
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
© 2002, Progress Software CorporationExchange 2002, Chicago, IL, USA 18
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 …
Client GUI Session AppServer Session
DB lookup…
© 2002, Progress Software CorporationExchange 2002, Chicago, IL, USA 19
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
Client GUI Session AppServer Session
Order Maint.
Pricingpolicy
Submit orderA
PI
API
API
© 2002, Progress Software CorporationExchange 2002, Chicago, IL, USA 20
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
© 2002, Progress Software CorporationExchange 2002, Chicago, IL, USA 21
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
Client GUI Session AppServer Session
Get property
Pricingpolicy
Submit orderA
PI
API
API
Clientproc2
Mainproc
© 2002, Progress Software CorporationExchange 2002, Chicago, IL, USA 22
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
© 2002, Progress Software CorporationExchange 2002, Chicago, IL, USA 23
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
© 2002, Progress Software CorporationExchange 2002, Chicago, IL, USA 24
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
© 2002, Progress Software CorporationExchange 2002, Chicago, IL, USA 25
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
© 2002, Progress Software CorporationExchange 2002, Chicago, IL, USA 26
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
© 2002, Progress Software CorporationExchange 2002, Chicago, IL, USA 27
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
© 2002, Progress Software CorporationExchange 2002, Chicago, IL, USA 28
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
© 2002, Progress Software CorporationExchange 2002, Chicago, IL, USA 29
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
© 2002, Progress Software CorporationExchange 2002, Chicago, IL, USA 30
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™
© 2002, Progress Software CorporationExchange 2002, Chicago, IL, USA 31
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
© 2002, Progress Software CorporationExchange 2002, Chicago, IL, USA 32
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.
© 2002, Progress Software CorporationExchange 2002, Chicago, IL, USA 33
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
© 2002, Progress Software CorporationExchange 2002, Chicago, IL, USA 34
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
© 2002, Progress Software CorporationExchange 2002, Chicago, IL, USA 35
2002Exchange
PROGRESS WORLDWIDE
Questions
top related