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

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

Software Architecture Start with a blank sheet

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

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

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.

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)

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.

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

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

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

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

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

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

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

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

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

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

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

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.

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.

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

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

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

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

Service Adapter Demo Create service adapter Change UI to match

Service Adapter Demo Create service adapter Change UI to match

Service Adapter Demo Create service adapter Change UI to match

Service Adapter Demo Create service adapter Change UI to match

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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’

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

Next steps Application Architecture Made Simple

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

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

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

Questions?