1. ARCH-1: Application Architecture made Simple
Intro
Christian Stiller
Applied Architect

2. Software Architecture
ProDatasets OO
“The software architecture of a system consists of software components, their external properties, and their relationships with one another.”
Presentation
Enterprise Services
Business Components
Data Access
What is ‘Software Architecture’? – A short description
Data Sources
Wikipedia – The free encyclopedia

3. Software Architecture
Start with a blank sheet

4. The Use Cases Display customer information Change customer information
Check premium access
Introduce the use cases

5. The Use Cases
Quick demo to show the UI, explain the story and use cases

6. Agenda The Break Up Matchmaking Dissociative Identity Disorder
Application Architecture
The Break Up
Matchmaking
Dissociative Identity Disorder
This section will briefly introduce the Use Cases used for this Architecture Introduction.

7. Before the Break Up UI and BL mixed
Hard to maintain
BL has UI knowledge
Code is duplicated in multiple screens
Not all instances of the code are changed consistently
BL is tied to specific screen
Adding new UI requires BL “re-write” (most often copy-paste and change)

8. Break Up goals Improve application maintainability Re-Use of BL
UI and BL can be changed independent of each other
Re-Use of BL
No code duplication if BL is used in multiple screens
Exposing services to other interfaces
Re-use of BL with other applications or UIs
Improved application maintainability
Making the user interface independent from the business logic and the database allows you to easily implement changes to the data structure or business rules without having to update the user interface as well. It also provides deployment benefits in certain configurations where you might not need to deploy code to the client machines for changes like this.
User interface independence
Because the business logic is separated, the user interface can be replaced with a new interface, or even an interface implemented in a different technology while re-using the existing business logic. You can also expose these business logic services to .NET or Java applications.
Exposing services to other interfaces
The services can also be used by non-user interfaces like batch jobs, integration services or automated requests. Another interesting option is automated testing using progress code to call the services and evaluate the responses.

9. Evolution of Architecture Layers
Separating UI from BL
User Interface
Business Logic
Database
Service Requester
Service Provider
QUERY
Result
DATA
Request

10. Break Up
Demo
Create services (one from scratch, just review the other two)
Hook up to UI (just fill in call)
Move files into BE internal procedure
Change UI to match
Key points
Easy to write, can do today
can change UI or DB without the other

11. Break Up
Demo
Create services (one from scratch, just review the other two)
Hook up to UI (just fill in call)
Move files into BE internal procedure
Change UI to match
Key points
Easy to write, can do today
can change UI or DB without the other

12. Break Up
Demo
Create services (one from scratch, just review the other two)
Hook up to UI (just fill in call)
Move files into BE internal procedure
Change UI to match
Key points
Easy to write, can do today
can change UI or DB without the other

13. Break Up
Demo
Create services (one from scratch, just review the other two)
Hook up to UI (just fill in call)
Move files into BE internal procedure
Change UI to match
Key points
Easy to write, can do today
can change UI or DB without the other

14. Break Up
Demo
Create services (one from scratch, just review the other two)
Hook up to UI (just fill in call)
Move files into BE internal procedure
Change UI to match
Key points
Easy to write, can do today
can change UI or DB without the other

15. Break Up
Demo
Create services (one from scratch, just review the other two)
Hook up to UI (just fill in call)
Move files into BE internal procedure
Change UI to match
Key points
Easy to write, can do today
can change UI or DB without the other

16. Break Up
Demo
Create services (one from scratch, just review the other two)
Hook up to UI (just fill in call)
Move files into BE internal procedure
Change UI to match
Key points
Easy to write, can do today
can change UI or DB without the other

17. Break Up
Demo
Create services (one from scratch, just review the other two)
Hook up to UI (just fill in call)
Move files into BE internal procedure
Change UI to match
Key points
Easy to write, can do today
can change UI or DB without the other

18. Break Up
Demo
Create services (one from scratch, just review the other two)
Hook up to UI (just fill in call)
Move files into BE internal procedure
Change UI to match
Key points
Easy to write, can do today
can change UI or DB without the other

19. Evolution of Architecture Layers
Separating UI from BL
User Interface
Business Logic
Database
Service Requester
Service Provider
QUERY
Result
DATA
Request

20. Break Up goals Improve application maintainability Re-Use of BL
UI and BL can be changed independent of each other
Re-Use of BL
No code duplication if BL is used in multiple screens
Exposing services to other interfaces
Re-use of BL with other applications or UIs
Improved application maintainability
Making the user interface independent from the business logic and the database allows you to easily implement changes to the data structure or business rules without having to update the user interface as well. It also provides deployment benefits in certain configurations where you might not need to deploy code to the client machines for changes like this.
User interface independence
Because the business logic is separated, the user interface can be replaced with a new interface, or even an interface implemented in a different technology while re-using the existing business logic. You can also expose these business logic services to .NET or Java applications.
Exposing services to other interfaces
The services can also be used by non-user interfaces like batch jobs, integration services or automated requests. Another interesting option is automated testing using progress code to call the services and evaluate the responses.

21. Agenda The Break Up Matchmaking Dissociative Identity Disorder
Application Architecture
The Break Up
Matchmaking
Dissociative Identity Disorder
This section will briefly introduce the Use Cases used for this Architecture Introduction.

22. Before the Matchmaking
Service location
Hard coded
Spread throughout application
Service signature
Service format is used as-is everywhere
Used in several places
Common Infrastructure
Mixed with BL and UI
Hard to make changes to signature

23. Before the Matchmaking
Demo
Create services (one from scratch, just review the other two)
Hook up to UI (just fill in call)
Move files into BE internal procedure
Change UI to match
Key points
Easy to write, can do today
can change UI or DB without the other

24. Evolution of Architecture Layers
Service Adapter & Service Interface
User Interface
Service Adapter
Service Interface
Business Logic
Result
Request
Service Requester
Service Provider

25. Service Adapter – Goals / Purpose
Isolate Service Requester
Make separation transparent
Provide Service Provider location independence
Isolate common infrastructure
Isolate requester from Service Provider format

26. Service Adapter
Demo
Create service adapter
Change UI to match

27. Service Adapter
Demo
Create service adapter
Change UI to match

28. Service Adapter
Demo
Create service adapter
Change UI to match

29. Service Adapter
Demo
Create service adapter
Change UI to match

30. Service Adapter – Goals / Purpose
Isolate Service Requester
Make separation transparent
Provide Service Provider location independence
Isolate common infrastructure
Isolate requester from Service Provider format

31. Evolution of Architecture Layers
Service Adapter & Service Interface
User Interface
Service Adapter
Service Interface
Business Logic
Result
Request
Service Requester
Service Provider

32. Service Interface – Goals / Purpose
Isolate Service Provider
Isolate Service Provider from Common Application Services
Security, Context etc.
Determine Service Provider Component to serve request
Isolate Service Provider from technology differences or requirements
Data formatting
Data transformation

33. Service Interface Demo
Create service interface (one from scratch, just review the other two)

34. Service Interface Demo
Create service interface (one from scratch, just review the other two)

35. Service Interface Demo
Create service interface (one from scratch, just review the other two)

36. Service Interface – Goals / Purpose
Isolate Service Provider
Isolate Service Provider from Common Application Services
Security, Context etc.
Determine Service Provider Component to serve request
Isolate Service Provider from technology differences or requirements
Data formatting
Data transformation

37. Evolution of Architecture Layers
Service Adapter & Service Interface
User Interface
Service Adapter
Service Interface
Business Logic
Result
Request
Service Requester
Service Provider

38. Location and common infrastructure
Demo
Add AppServer
Add security
Key points
Can change BL location or add CI without changes to UI or BL

39. Location and common infrastructure
Demo
Add AppServer
Add security
Key points
Can change BL location or add CI without changes to UI or BL

40. Location and common infrastructure
Demo
Add AppServer
Add security
Key points
Can change BL location or add CI without changes to UI or BL

41. Location and common infrastructure
Demo
Add AppServer
Add security
Key points
Can change BL location or add CI without changes to UI or BL

42. Location and common infrastructure
Demo
Add AppServer
Add security
Key points
Can change BL location or add CI without changes to UI or BL

43. Location and common infrastructure
Demo
Add AppServer
Add security
Key points
Can change BL location or add CI without changes to UI or BL

44. Evolution of Architecture Layers
Service Adapter & Service Interface
User Interface
Service Adapter
Service Interface
Business Logic
Result
Request
Service Requester
Service Provider

45. Agenda The Break Up Matchmaking Dissociative Identity Disorder
Application Architecture
The Break Up
Matchmaking
Dissociative Identity Disorder
This section will briefly introduce the Use Cases used for this Architecture Introduction.

46. Business Logic – The Current Situation
Logic uses physical data storage
Complex joins
Confusing fields names
Changes to business rules require knowledge of physical data storage
Changes to physical data storage require changes to implementation of business rules
Database schema changes
Use of different data source

47. Business Logic – The Goals
Responsibility split…
A Business View of Data (Logical Model)
Independent of physical storage (Physical Model) – meaningful names
Simplified view (more natural fit)
Improved Application Maintenance
Changing Business Logic does not impact Data Source or User Interface
Changing User Interface or Data Source does not impact Business Logic

48. A Business View of Data
Customer Entity
Name
Street
City
State
Logical Model
Customer Table
First Name
Last Name
Address Table
Number
State Table
Code
Description
Physical Model
Makes Business Logic independent of Physical Model
Makes Business Logic more ‘natural’

49. Business Components and Data Access
Data Transformation & Flow
OpenEdge DB
dbCustomer
Data Access Object
ttCustomer
Business Component
This slide shows the data flow for a Customer service (any type). The Customer records are held in the OpenEdge Database and are requested by the Data Access Object (DAO). The Customer records from the DB (Physical Data Model) will be read into a Data Transport Unit (ttCustomer TEMP-TABLE in this case) that makes a Logical Data Model. Key here is that the Physical and Logical Data Models do not have to be the same. In fact, these can be substantially different. This is where the DAO proves its value. The DAO then sends the ttCustomer data structure to the Business Entity (BE) where it can be used in Business Logic (Domain Specific Code).
Key again here is that the Business Logic is written against this Logical Data Model (the ttCustomer data) which is independent of the Physical Data Model (the DB storage in this case). This means that changing the DB structure does not affect the BL because the DAO will cater for the change. Getting the data from XML files instead of a DB is not going to affect the BL either because of the same isolation provided by the DAO.

50. Evolution of Architecture Layers
Business Component and Data Access
Service Interface
Business Component
Data Access
Data Source
Request
Result
Service Provider

51. Data Access Demo Identify BL / DA code
Move code around, visually seperate
Create DA object, call from BE (for one, have others prepared
Cut & paste stuff
Key points

52. Data Access Demo Identify BL / DA code
Move code around, visually seperate
Create DA object, call from BE (for one, have others prepared
Cut & paste stuff
Key points

53. Data Access Demo Identify BL / DA code
Move code around, visually seperate
Create DA object, call from BE (for one, have others prepared
Cut & paste stuff
Key points

54. Data Access Demo Identify BL / DA code
Move code around, visually seperate
Create DA object, call from BE (for one, have others prepared
Cut & paste stuff
Key points

55. Data Access Demo Identify BL / DA code
Move code around, visually seperate
Create DA object, call from BE (for one, have others prepared
Cut & paste stuff
Key points

56. Data Access Demo Identify BL / DA code
Move code around, visually seperate
Create DA object, call from BE (for one, have others prepared
Cut & paste stuff
Key points

57. Data Access Demo Identify BL / DA code
Move code around, visually seperate
Create DA object, call from BE (for one, have others prepared
Cut & paste stuff
Key points

58. Data Access Demo Identify BL / DA code
Move code around, visually seperate
Create DA object, call from BE (for one, have others prepared
Cut & paste stuff
Key points

59. Data Access Demo Identify BL / DA code
Move code around, visually seperate
Create DA object, call from BE (for one, have others prepared
Cut & paste stuff
Key points

60. Data Access Demo Identify BL / DA code
Move code around, visually seperate
Create DA object, call from BE (for one, have others prepared
Cut & paste stuff
Key points

61. Evolution of Architecture Layers
Business Component and Data Access
Service Interface
Business Component
Data Access
Data Source
Request
Result
Service Provider

62. Evolution of Architecture Layers
OpenEdge® Reference Architecture
Presentation
Common Infrastructure
Enterprise Services
User Interface
Service Adapter
Service Interface
Business Component
Data Access
Data Source
Business Components
Data Access
Data Sources

63. Next steps
Application Architecture Made Simple

64. Next steps PSDN – OpenEdge Principles OpenEdge 10
Application Architecture Made Simple
OpenEdge Reference Architecture
OpenEdge 10
OpenEdge Architect
ProDataSet™ OO

65. Relevant Exchange Sessions
INT-9: Implementing ESB Processes with OpenEdge and Sonic
David Cleary
Relevant Exchange Sessions
ARCH-2: OERA Latest Thinking!
ARCH-5: Modeling - From Design to Implementation in OpenEdge using UML and MDA
ARCH-7: A Classed-Based Implementation of the OERA
ARCH-14: Power Your Organization with OpenEdge

66. Relevant Exchange Sessions
INT-9: Implementing ESB Processes with OpenEdge and Sonic
David Cleary
Relevant Exchange Sessions
DEV-7: The OpenEdge Architect Experience
DEV-24: Adopting and Using OpenEdge Architect
DEV-5: Using ProDataSet in OpenEdge 10
DEV-6: Getting Started with Object-Oriented Programming
DEV-20: Using Classes and Procedures in ABL

67. Questions?