What is Architecture  Architecture is a subjective thing, a shared understanding of a system’s design by the expert developers on a project  In the form of the major components and how they interact with each other  It is about decisions – decisions that are very hard to change  If it is easy to change, it is not architectural.

Enterprise Applications  Persistent data – a lot of data  Access data concurrently  A lot of user interface screens  Integrate with other enterprise applications  Different business processes and conceptual dissonance  Complex “business illogic”

Examples of Enterprise Apps  B2C Online Retailer  Straightforward domain/business logic  Very high volumes of users  Easy access – web presentation  Leasing Agreement Processing System  Very complex business logic  No so many users  Complex user interface – rich client UI  Long business transactions in time  Expense-Tracking for a Small Company  Not many users  Simple business logic  Integrate with payroll, reservation, etc

Architecture Design  There is no ONE architecture that fits all different kinds of apps  Choosing an architecture:  You have to understand the particular problem of your system and choose an appropriate design based on that understanding

The Three Principal Layers  Presentation Logic  Handle the interaction between the user and the software  Display information to the user  Interpret commands from the user into actions  Data Source Logic  Communicate with other systems  Transaction monitor  DBMS  Domain Logic  Business logic  Use input and stored data to produce output  Decide what data sources to persist data

The Three Principal Layers  Presentation is an external interface for a service your system offers to someone else  Data source is the interface to things that are providing a service to you.  The domain normally hides the data source from the presentation  The domain and data source should never be dependent on the presentation

The Three Principal Layers  Domain or presentation logic?  A test: adding a different UI, if any functionality needs to be duplicated, it should be in the domain.  Another example:  If this month’s sales are 10% higher than last month, display this month’s sales in red  Domain: a method deciding if it is 10% higher  Presentation: if true, highlight the sales   tion.html tion.html

Deployment of the Layers  Presentation Logic  Rich client: on the client  HTML: on the server  Data Source  Almost always on servers  Domain Logic  All on the server – easy maintenance  All on the client – better responsiveness  Split – isolate the piece on the client

Organizing Domain Logic  Three Primary Patterns:  Transaction Script  Domain Model  Table Model  Service Layer

Transaction Script  Suitable for systems with simple domain logic  A procedure that takes the request, processes it, stores data in DB, invokes external operations, replies back to the user  One procedure per user action/business transaction  Advantages:  Easy for developers to understand  Facilitate transaction boundaries  Disadvantages:  Potential for duplicate code  Cause tangled web of routines

Domain Model  Suitable for systems with complex logic  Build a model with domain objects which are nouns in the business  Each object takes part of the logic for a user action  Advantages:  Handle complex logic in a well-organized way  Disadvantages:  Hard for developers to learn  Leads to complex data source layer

Table Module  Middle ground between Transaction Script and Domain Model  One table module (a class) represents a table in the DB.  Designed to work with Record Sets  Advantages:  Many GUI components could use the Record Sets returned from table modules

Service Layer  Often works with Domain Model and Table Module  Placed over domain model or table module  Can handle transaction control and security  How much behavior in service layer:  Service layer as a façade – an API to underlying objects, or  Most business logic is in scripts in service layer and underlying objects are very simple, or  Put logic particular for a transaction or use case as transaction scripts in the layer – Controller Entity

Mapping to Relational Database  Four Patterns:  Table Data Gateway  Row Data Gateway  Active Records  Data Mapper  Behavioral Patterns:  Unit of work  Lazy load

Structural Mapping Patterns  Structural Mapping Patterns:  Identity Field  One-to-one: Foreign Key Mapping  One-to-many: Foreign Key Mapping/Dependent Mapping  Many-to-many: Association Table Mapping  Inheritance  Single Table Inheritance  one table for the whole hierarchy  Concrete Table Inheritance  one table for each concrete class including its all ancestors  Class Table Inheritance  One table for each class, concrete or abstract

Web Presentation  Model View Controller  Application Controller  Handle the flow of the app  View Patterns  Transform View  Template View  Two Step View  Handle different devices  Input Controller Patterns  Page Controller  Front Controller

Concurrency  Offline Concurrency  Concurrent control for data that’s manipulated during multiple DB transactions  Concurrency Problems  Lost Update  Inconsistent read  Execution Context  Request context  Session context  DB transaction context

Isolation and Immutability  Isolation  Partition data so that any piece of it can only be accessed by one active agent  Immutable data  Identify immutable data to improve concurrency

Concurrency Control  Optimistic Locking  Conflict detection  Pessimistic Locking  Conflict prevention  Reduces concurrency  Preventing inconsistent reads  Deadlocks

Transactions  ACID  Atomicity, Consistency, Isolation, Durability  Transactional Resources  Reducing Transaction Isolation for Liveness  Business and System Transactions

Patterns for Offline Concurrency Control  Optimistic Offline Lock  Pessimistic Offline Lock  Coarse-Grained Lock  Implicit Lock

Application Server Concurrency

Session State  Stateless vs Stateful sessions  Session State  Client Session State  Server Session State  Database Session State  Session Migration  Session Affinity

Distribution Strategies  Distributed Objects  Remote and Local Interfaces  First Law of Distributed Object Design:  Don’t distribute your objects  Where you have to distribute:  Client – server  Server and database  Web server and app server  Different vendors

Working with Distribution Boundaries  Remote Façade  Coarse grained objects at distribution boundaries  Data Transfer Object or Value Object  Coarse grained objects need to be transferred between the two distributed parties  Lazy Load  Lazy reading data from remote services  Caution: not lose any data

Interfaces for Distribution  XML-based HTTP  Web Service  Use it when different platforms need to talk  Synchronous  Asynchronous

Putting It All Together