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

© 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA 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

© 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA 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

© 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA 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”

© 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA 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

© 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA 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

© 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA 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

© 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA 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

© 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA 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

© 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA 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

© 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA 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 ?

© 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA 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…

© 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA 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?

© 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA 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 !

© 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA 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

© 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA 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

© 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA 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

© 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA 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…

© 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA 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

© 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA 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

© 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA 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

© 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA 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

© 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA 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

© 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA 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

© 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA 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

© 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA 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

© 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA 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

© 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA 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

© 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA 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

© 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA 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™

© 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA 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

© 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA 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.

© 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA 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

© 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA 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

© 2002, Progress Software Corporation Exchange 2002, Chicago, IL, USA Exchange PROGRESS WORLDWIDE Questions