Title: DEV5: Application Architecture Made Simple
1DEV-5 Application Architecture Made Simple
Christian Stiller
Technical Account Manager
2Software Architecture
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 Sources
Wikipedia The free encyclopedia
3Software Architecture
4The Use Cases
- Display customer information
- Change customer information
- Check premium access
5The Use Cases
6Agenda
Application Architecture
- The Break Up
- Matchmaking
- Multiple Personality Disorder
7Before 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)
8Break Up goals
- Improve application maintainability
- 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
9Evolution of Architecture Layers
Separating UI from BL
DATA
Result
QUERY
Request
10Break Up
11Break Up
12Break Up
13Break Up
14Break Up
15Break Up
16Break Up
17Break Up
18Break Up
19Evolution of Architecture Layers
Separating UI from BL
DATA
Result
QUERY
Request
20Break Up Goals
- Improve application maintainability
- 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
21Agenda
Application Architecture
- The Break Up
- Matchmaking
- Multiple Personality Disorder
22Before 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
23Before the Matchmaking
24Evolution of Architecture Layers
Service Adapter Service Interface
Result
Request
Service Requester
Service Provider
25Service Adapter Goals / Purpose
- Isolate Service Requester
- Make separation transparent
- Provide Service Provider location independence
- Isolate common infrastructure
- Isolate requester from Service Provider format
26Service Adapter
27Service Adapter
28Service Adapter
29Service Adapter
30Service Adapter Goals / Purpose
- Isolate Service Requester
- Make separation transparent
- Provide Service Provider location independence
- Isolate common infrastructure
- Isolate requester from Service Provider format
31Evolution of Architecture Layers
Service Adapter Service Interface
Result
Request
Service Requester
Service Provider
32Service 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
33Service Interface
34Service Interface
35Service Interface
36Service 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
37Evolution of Architecture Layers
Service Adapter Service Interface
Result
Request
Service Requester
Service Provider
38Location and common infrastructure
39Location and common infrastructure
40Location and common infrastructure
41Location and common infrastructure
42Location and common infrastructure
43Location and common infrastructure
44Evolution of Architecture Layers
Service Adapter Service Interface
Result
Request
Service Requester
Service Provider
45Agenda
Application Architecture
- The Break Up
- Matchmaking
- Multiple Personality Disorder
46Business 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
47Business 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
48A Business View of Data
- Makes Business Logic independent of Physical
Model - Makes Business Logic more natural
49Business Components and Data Access
Data Transformation Flow
50Evolution of Architecture Layers
Business Component and Data Access
Result
Request
Service Provider
51Data Access
52Data Access
53Data Access
54Data Access
55Data Access
56Data Access
57Data Access
58Data Access
59Data Access
60Data Access
61Evolution of Architecture Layers
Business Component and Data Access
Result
Request
Service Provider
62Evolution of Architecture Layers
OpenEdge Reference Architecture
63Next steps
- Application Architecture Made Simple
64Next steps
- PSDN OpenEdge Principles
- Application Architecture Made Simple
- OpenEdge Reference Architecture
- OpenEdge 10
- OpenEdge Architect
- ProDataSet
- OO
65Relevant Exchange Sessions
- DEV-11 Architecting Your Application in OpenEdge
10 - DEV-17 Getting to SaaS
- DEV-18 Estimating Your TransformationThe Reality
66Relevant Exchange Sessions
- DEV-1 What's New in OpenEdge 10.1C?
- DEV-2 Making OpenEdge Architect Work for You
- DEV-6 Introduction to the OpenEdge Advanced GUI
- DEV-12 What's New in the Object-Oriented ABL?
- DEV-24 What's New with ProDataSets in 10.1C?
67?
Questions
68Thank You
69(No Transcript)