1. 2002 Exchange PROGRESS WORLDWIDE Session C10: Modernizing Your Applications John Sadd, Engineering Fellow the Progress Company

2. © 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA2 2002 Exchange PROGRESS WORLDWIDE Goals for this session n 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

3. © 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA3 2002 Exchange PROGRESS WORLDWIDE Agenda What’s a “modern” application? Database design Separating UI from Logic Factoring out common code Migrating existing applications How Progress Dynamics™ supports these goals

4. © 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA4 2002 Exchange PROGRESS WORLDWIDE First, what’s a “Traditional” Progress application? n Character-based –Looks the same on any platform –Or GUI client-server n Host-based or client-server –Always a direct database connection n Built with the 4GL and Progress DB –Limited DataServers, no external interfaces n Static data references in the 4GL –Tables and fields resolved at compile time –Include files or preprocessors for “reuse”

5. © 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA5 2002 Exchange PROGRESS WORLDWIDE So what are the “Modern” application requirements? n Graphical interface –Windows and/or Web UI n Distributed application –Remote clients –More extensive security requirements n More databases and interfaces –DataServers –Integration with reporting and other tools n Dynamic 4GL table and field references n Variety of languages, design tools, connectivity

6. © 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA6 2002 Exchange PROGRESS WORLDWIDE How has Progress evolved to meet these requirements? Progress RDBMS -Personal -Workgroup -Enterprise DataServer Oracle WebClient WebSpeed Browser Client WebSpeed Transaction Server AppServer GUI Client Open Clients Load Balancer Dynamics Framework Character Client SQLServer ODBC MANAGERS: Connection Session Profile Security Localization Name Server ESQL/C SQL-92 PDA Wireless Application Business Components: Smart Business Obj Smart B2B Object Dynamic SDO 4GL Sonic SQL 4GL DataServer Progress 4GL ADM Sonic MQ Adapter Legacy Applications Custom or Packaged Applications Progress or Non-Progress Applications Webspeed Messenger AppServer Internet Adapter APIs TCP/IP HTTP/S HTTP HTTPS XML, ProxyGen or Sonic MQ Repository Database Sonic MQ Server EJB Server Any Client Any Business Any Data Source Any Application Non-English Support Progress Non-Progress

7. © 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA7 2002 Exchange PROGRESS WORLDWIDE What are the central problems for new applications? n The world is more complex n 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

8. © 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA8 2002 Exchange PROGRESS WORLDWIDE Agenda What’s a “modern” application? Database design Separating UI from Logic Factoring out common code Migrating existing applications How Progress Dynamics™ supports these goals

9. © 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA9 2002 Exchange PROGRESS WORLDWIDE Special Progress database and schema characteristics n Arrays n Validation logic defined in the schema n “Database” trigger procedures n Special data-related language constructs –Complex nested logic for data retrieval –CAN-FIND –FIND NEXT with different indexes –SHARE-LOCK and EXCLUSIVE-LOCK

10. © 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA10 2002 Exchange PROGRESS WORLDWIDE Arrays vs. joins -- Issues n SQL Access n Open client n Indexing n Client display SalesRepRepNameQuota[1] Quota[2] Quota[3] Quota[4] SalesRepRepNameQuota SalesRep Month joined table array

11. © 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA11 2002 Exchange PROGRESS WORLDWIDE Validation Logic -- Issues n Compiled into UI n Requires local DB n No external access ON LEAVE… IF CAN-FIND… Client GUI SessionAppServer Session ?

12. © 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA12 2002 Exchange PROGRESS WORLDWIDE Trigger Procedures -- Issues n Execute on client in C/S (expensive) n No UI on Server for MESSAGEs n Often hold real Business Logic ASSIGN … Client GUI SessionAppServer Session IF THEN MESSAGE… Trigger ON WRITE…

13. © 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA13 2002 Exchange PROGRESS WORLDWIDE Complex navigation logic -- Issues n Doesn’t map to queries n Poor SQL access n 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?

14. © 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA14 2002 Exchange PROGRESS WORLDWIDE Record Locking -- Issues n SHARE-LOCK and SQL n No locks across AppServer boundary DO TRANSACTION: FIND … EXCLUSIVE-LOCK. END. Client GUI SessionAppServer Session !

15. © 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA15 2002 Exchange PROGRESS WORLDWIDE Tradeoffs in database design and application migration n Some Progress “traditions” need to be sacrificed or rethought n How bad is your existing database design? n How much existing business logic can you realistically reuse? n Balance DB schema changes against resulting changes to “salvaged” code n Consider third-party DB access as well as your direct application needs n There’s no single right answer

16. © 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA16 2002 Exchange PROGRESS WORLDWIDE Agenda What’s a “modern” application? Database design Separating UI from Logic Factoring out common code Migrating existing applications How Progress Dynamics™ supports these goals

17. © 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA17 2002 Exchange PROGRESS WORLDWIDE Basic principles of a modern distributed application n Assume NO client database access n Plan to reuse business logic n Anticipate customization n Your “client” and “server” will be different sessions n Allow for non-Progress clients

18. © 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA18 2002 Exchange PROGRESS WORLDWIDE No client database access means… n No CAN-FIND n Less immediate feedback n Minimize client B.L. n Minimize AppServer hits CAN-FIND … Client GUI SessionAppServer Session DB lookup…

19. © 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA19 2002 Exchange PROGRESS WORLDWIDE Reusing Business Logic means… n Encapsulate B.L. n Break logic down n Separate out complex B.L. n Make no assumptions n Avoid prompts / UI in B.L. RUN PricingProc In AShandle Client GUI SessionAppServer Session Order Maint. Pricing policy Submit order APIAPI APIAPI APIAPI

20. © 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA20 2002 Exchange PROGRESS WORLDWIDE Planning for customization means… n Allow for translation n Define levels of customization n Associate security with UI n Define customization hooks n Store customization data Label: Menu/text translation Data translation Security User preferences Customization data Customization manager

21. © 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA21 2002 Exchange PROGRESS WORLDWIDE Client and server in different sessions means… n No shared variables n Clean interface n No hierarchy n Use a property API Client proc1 Client GUI SessionAppServer Session Get property Pricing policy Submit order APIAPI APIAPI APIAPI Client proc2 Main proc

22. © 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA22 2002 Exchange PROGRESS WORLDWIDE Allowing for non-Progress clients means… n Provide alternatives to Progress API n Consider XML n Design your API to allow for this Client SessionAppServer Session Order Maint. Pricing policy Submit order APIAPI APIAPI APIAPI XML

23. © 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA23 2002 Exchange PROGRESS WORLDWIDE How bad is my old code? n Monolithic “spaghetti” code is the bane of any migration plan n 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

24. © 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA24 2002 Exchange PROGRESS WORLDWIDE Agenda What’s a “modern” application? Database design Separating UI from Logic Factoring out common code Migrating existing applications How Progress Dynamics™ supports these goals

25. © 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA25 2002 Exchange PROGRESS WORLDWIDE “Traditional” Progress constructs for code reuse n Include files with parameters n Preprocessor values n Code generators n 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

26. © 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA26 2002 Exchange PROGRESS WORLDWIDE Dynamic 4GL features can help n Dynamic widgets n Dynamic buffers, queries, and temp-tables n Dynamic function call syntax n Dynamic CALL syntax (in 9.1D) n 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

27. © 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA27 2002 Exchange PROGRESS WORLDWIDE “Modern” Progress procedures n Not top-down n Use persistent procedures as libraries n Use super procedures for inheritance n Eliminate redundant procedures n Store the “parameters” for them Persistent procedure library Super Procedure “class” Application code Procedure parameters RUN IN… Inherit Parameterize

28. © 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA28 2002 Exchange PROGRESS WORLDWIDE Agenda What’s a “modern” application? Database design Separating UI from Logic Factoring out common code Migrating existing applications How Progress Dynamics™ supports these goals

29. © 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA29 2002 Exchange PROGRESS WORLDWIDE So how do I get from here to there? n Make essential changes to your database –But don’t do a whole redesign if you have logic to salvage n Devise ways to “wrap” B.L. and reports n Be realistic about rethinking your UI –Your old frames and procedure flow just may not make sense in GUI or on the Web n Balance choices between redesign and salvage –There’s no single right answer

30. © 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA30 2002 Exchange PROGRESS WORLDWIDE When is a rewrite not really a rewrite? n …When you eliminate a lot of redundant code n …When you let a standard framework take care of a lot of the “modernizing” for you n …When you wrap your business logic and reports to be callable in new ways n 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™

31. © 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA31 2002 Exchange PROGRESS WORLDWIDE Agenda What’s a “modern” application? Database design Separating UI from Logic Factoring out common code Migrating existing applications How Progress Dynamics™ supports these goals

32. © 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA32 2002 Exchange PROGRESS WORLDWIDE You don’t have to use Progress Dynamics, but… n Progress Dynamics provides an architecture for distributed applications n UI generation is provided n Old code is replaced by standard behavior –Navigation, Updates, Lookups, etc. n Manager utilities provide standard support –Security, user maintenance, localization, connection management, etc.

33. © 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA33 2002 Exchange PROGRESS WORLDWIDE To summarize… n Assess honestly which parts of your DB and application can be salvaged –and which will really benefit from redesign n 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 n Take advantage of advances in language and tools n Consider the big picture – it’s more than just Progress

34. © 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA34 2002 Exchange PROGRESS WORLDWIDE Goals met? n 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

35. © 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA35 2002 Exchange PROGRESS WORLDWIDE Questions