Enterprise Software Architecture Patterns

• Patterns of Enterprise Software Architecture address software architecture patterns.

Introduction

• Structuring business applications is a key objective.
• Architecture includes the main application parts and their connections.
• Architectural patterns involve important decisions about these components
• Design patterns assist in realizing the architecture.

Sample Business Applications

• Online Store (B2C) features many users, simple business logic for orders, price calculations, and a generic web interface.
• It uses a database for orders and inventory
• Processing house renting features few users and complex business logic for bills, overdrafts, and contract validation.
• It offers a complex user interface and database integrated with external packages for asset valuation and pricing
• Small company expenses management is scalable for future growth and integrates with other applications

Patterns

• A pattern describes a common problem and provides guidelines to solve it

Layered Architecture

• Layered Architecture helps decompose complex problems.
• The top layer uses services from the bottom layer, but the bottom layer is unaware of the top one
• The bottom layer typically hide ones below to upper levels.
• Benefits include needing to know only the layer below, independent replacement of layers, minimized dependencies, and layer reuse
• Disadvantages include the risk of cascading changes, reduced performance, and difficulty in deciding layer functionality

3-Layer Architecture

• Presentation layer is the user-application interaction logic using command line, menus, rich client, or HTML
• Data Sources layer communicates with systems providing data like transaction monitors, legacy systems, or databases
• Domain Logic is application-specific functionality for validating tickets, generating invoices, or computing problems

Layer Execution

• Layer separation is useful even on a single computer
• Everything can be managed on the server with HTML presentation for instance
• Client-side can offer better responsiveness and offline operation with an installable client application (Applet, App, etc.)

Transaction Script

• Transaction Script is a simple domain logic pattern where a procedure receives parameters from presentation, processes them, stores/retrieves data, invokes other systems, and responds with data
• It works well with simple data and has obvious transaction limits, but is too simple for complex domain logics which require the Domain Model Pattern

Transaction Script Example

• An online store uses Transaction Scripts to add products to cart, checkout, and check order status

Domain Model

• Domain Model is a pattern based on the use of objects, suitable for complex domains
• The more complex the domain, the more difficult is the mapping to relational DBs

Table Module

• Table Module is an alternative, designed to operate with a Record Set (DB query result)
• It is a compromise between Transaction Script and Domain Model (Domain structured with tables)
• Table Module misses inheritance of OO patterns and is ideal for technologies like .NET

Remote Interfaces to Domain Logic

• HTTP Interfaces through a browser or web service using HTML, JSON, XML formats are nearly universal and easy to deploy
• The disadvantage is a less explicit interface specification via XML Schema or API documents
• OO interfaces like CORBA, ActiveX, or Java RMI have explicit interface specifications with methods and parameters but may be complex to configure

Web Presentation

• Web Presentation enables user interfaces based on web browsers offering no software installation, a common UI and universal access
• A Web Server interprets URLs and passes control to the corresponding web application
• Main structural elements include scripts with HTTP processing and server pages with HTML templates
• Model View Controller (MVC) pattern applies: a controller receives the HTTP request, redirects to the appropriate model object, queries data sources, and the view receives the response using HTTP session object and displays it

View Patterns

• Three patterns for views are Transform View, Template View, and Two Step View
• Transform and Template View have one stage, Two Step View has two stages applying to either Transform or Template View

Template View

• With Template View page structure defines presentation with markers for dynamic code, typically on server pages.
• Template View offers easy development.
• The code can be messy and harder to maintain

Transform View

• Transform View using languages like XSLT to transform XML data generated from the model
• With Transform View, Controller selects and applies the transformation to XML from the model
• It is adaptable to formats or devices, but complex

View Pattern Stages

• A view pattern can have one or two stages.
• 1 Stage: each screen is a view component, Template or Transform View
• 2 Stages: e.g Two Steps View pattern. It is the first step producing logical display and second one final display, HTML presentation.

Two Steps View

• One first step for each display, only one second step for the entire application
• Decisions can be centralized facilitating changes and is appropriate when different screens share basic design
• Introduces more complexity

Controller Patterns

• Page Controller uses a Controller object for each page or action.
• Front Controller isolates responsibilities to process and serve HTTP requests
• Centralizes request management by receiving all requests and creating secondary objects

Mapping to Relational DB

• Mapping to Relational DB is challenging because it stores objects in relational databases with different data structures to those in memory
• Alternatives include Object DBs which are risky as they aren't as developed

RDB Architectural Patterns

• Row Data Gateway, Table Data Gateway, Active Record, and Data Mapper map to relational databases

Gateway Pattern

• It is a basic pattern for Row and Table Data Gateways, mapping DB tables to in-memory classes with a field per DB column, containing all mapping code not domain logic.

Patterns Based on Gateway

• The choice is between Row and Table Data Gateways
• Table Data Gateway is easier if the technology supports the Record Set data recovery pattern
• Row Data Gateway works best otherwise
• An object is used for each record

Active Record Pattern

• Appropriate for when the domain model is similar to database schema.
• Combining the Gateway with the domain object in one class, includes database access and business logic.
• Separating these responsibilities is recommended

Data Mapper Pattern

• More complex but more flexible than Active Record, with domain objects independent from DB schema
• Is more complex, it is possible to reuse Object-Relational Mapping tools for complex mappings

Concurrence

• Objects must be loaded/saved and changes tracked, guaranteeing persistence while avoiding object changes in the DB while loaded

Unit of Work

• With Unit of Work loaded and modified objects are registered, and updates are managed to the database
• In this case the domain layer decides when to read and write
• Unit of Work pulls this behavior to a specific object.

Data Reading

• Mapping classes encapsulate SQL for object-relational mapping, e.g search methods and SQL "SELECT" commands
• Identity Map controls what is read
• Identity Map is also maintained in the Unit of Work object

Mapping Data Structures

• Mapping domain model objects to relational DB data has problems
• Relational DBs use foreign keys instead of object references
• Collections use one DB value per field
• Identity Field keeps track of the object's identify and helps mapping between objects and relational DB keys

Data Mapping Structures

• When reading a foreign key, and if it is not yet in the Identity Map, load object from DB using key.
• When storing object, references are replaced by the referenced entity Identity Field
• When reading or saving a collection, retrieve or store rows linked to the identifier of the object that includes the collection

Inheritance

• Relational databases commonly lack an inheritance mechanism
• Three Options: Single Table Inheritance, Concrete Table Inheritance or Class Table Inheritance.

Inheritance (Options)

• Single Table Inheritance: A table to store all classes
• Concrete Table Inheritance: A table for each concrete class
• Class Table Inheritance: One table for per class, stored fields just in the corresponding table

Inheritance (Tradeoffs)

• Choices involve duplication, flexibility and access speed tradeoffs.
• Class Table Inheritance avoids duplication, but is inefficient, needs many JOINS and is very flexible
• Concrete Table Inheritance has some duplication and less flexible as domain changes affect many tables but is more efficient because it uses less JOINS
• Single Table Inheritance has a lot of duplication, is affected by each domain change, but is efficient and uses no JOINS

Mapping Metadata

• Metadata Mapping facilitates reuse of mapping tools, informs the mapping process, how Columns correspond to object fields, and facilitates generating the mapping code
• They are commonly used in commercial tools.

Concurrence

• Multiple processes or threads manipulate the data
• Within a transaction, Request/Response prevents currency issues
• The issue happens in interactions among different transactions
• Multiple request/responses lead to concurrency control spanning multiple transactions, interaction involving, called offline concurrency

Concurrency Problems

• Lost Updates: User A edits, then user B edits the same file. B ends and then A, overwriting B's version
• Inconsistent readings: data readings are correct separately but if simultaneously will produce incorrect results
• These problems can be avoided with concurrency control mechanisms

Execution Contexts

• Interaction contexts involve Requests from outside the system, sessions of related client-server interactions, and request/responses between logging in and logging out.
• Processing contexts include processes (heavyweight, isolating data), threads (lightweight, sharing memory), and DB Access context, coordinate requests.

Isolation

• Isolation is a mechanism to avoid concurrency problems resulting from multiple processes or threads accessing the same data by coordinating access
• Operating system memory access mechanisms or file locks can be used

Concurrency Controls

• Shared data means coordinate concurrent access
• Measures of concurrency control is pessimistic and optimistic.
• In the "2 users edit simultaneously" scenario, is used each of them

Concurrency Controls - optimistic locking

• Focus on detecting conflict

1. Both users copy and edit file freely
2. When #2 tries to save, conflict detection occurs
3. User #2 can't save, options: discard, merge, new file,...

Concurrency Controls - pessimistic locking

• Focuses on preventing conflict

1. User#1 starts and the file is blocked for others
2. No one else can edit until #1 saves

Concurrency Control Preferences

• Optimize when there is rare consequences/conflicts, higher concurrent degrees.
• Pessimist when high risk due to conflicts.

Inconsistent readings

• Pessimistic locks will avoid.
• Reading requires read lock (shared by readers).
• Writing requires write lock (exclusive).
• Many users can read concurrently if someone is reading and no one can write.
• The requested writing in Write block - no one can read/write.

Deadlock

• Is a Pessimistic locking problem. Deadlocks:
• Example: 2 users editing, completing work, needed files.
• Options to avoid: -Deadlock detection. Can brake it. A victim will release all locks. -All Locks with expiry. -All locks obtained at user work session's beginning. Order blocks if desired.

Transactions

• Is the general concurrency control implemented in enterprise APPs.
• Is a certain amount of actions, with start and ending-points.
• Applied to DBs, printers queues, message-queues etc.
• A better performance if the amount of single request's transactions is small.

Transaction Properties

• Atomicity: complete all actions, or none.

• consistency: consistent resourced state during beginning and end.

• Isolation: The full result not visible as successful completed is.

• Persistence: successful results as full stored.

Business Transactions and System Transactions

• System: the SQL commands to close transactions,

• Business: Online system. A: selected account. B: payment made. C: OK Clicked.

Business Transactions Issues

• Problems with concurrency to face.
• Fitting Business between system ones.
• More requests.
• If time between requests; session locks for the system and prevent action.

Business Transactions (changes in sessions)

Atomicity and persistence: changing depends on agree of user.

• Keep tracks of change if necessary.

• Maintain consistency: application is responsible.

• Isolation: no one overwrite other for the session done.

Offline Concurrency Issues - resolution

• Concurrency request more and are patterns.
• Optimal Offline lock. Business lock: optimistic. -More easy but detectable change.
• Prevent of more easy. Loss occurs at the end.

Distribution Strategies (Contents)

• Distribute for APPs, with communication with remote objects, Objects can be design APP during implementation with extra components. Everyone processed at separate nodes.

Local and Remote Interface

• Distributed objects - the level of distribution - the efficiency is an problem,.

• A call from a machine is more slower the 1 at one machine.

• Differentiate to know the callable objects local and remote.

• For local Interface: calls are lot with simple functionality and is not a problem. (e.g: the 3 addresses needed etc..)

• For Remo Interface: call for certain action/functionality is provided in low calls and more efficient. Less calls. If flexible... . (e.g: One address Method.)

• Avoid recommended calls and objects if is possible.

• Alternative: the horizontal scalability ( computer replicas APPs a lot to serve the customers).

• Objects into single Machine to avoid issues.

• Multiple copied Machines to be executed during the APP using to everyone with that kind of action.

Distribution scenarios

• Remote calls sometimes .Client to server - with two machines. .DB to APP - Issues for avoid - data share synchronization with improve performance. Use SQL -to minimize and is prepare everything

Distributed object pattens

• "Remove facade" called remotely from an interface and builds above simpler in
• the end ( local method )
• Data with transfer to avoid more amount data and with a simple look is a local object.
• To return objects to simple call ( remote )

Putting into practice

• These patterns guideline to the dev business APP.
• Layers
• Platform's options

Domain Layer

• The following can be used at layer:

1. Script transaction: procedure + simple.
2. Domain: Difficult to relation DB(complex/ easy). 3.Table to module. Medium with complex DB in DB

Data Layer

• Depends on the choice of Domain: 1.DB/Trans Script( with a row table /DATA Gateway
• Problems minimize.
• Data load: to edit the solution is: offline lock ( Optimal and Apply)

Data layers

• table module with table data-gateway module if is possible.
• Records with Unit of Work for more control.

Data: layer of Models

• model depending on the complexity of Models or Domain
• for more complex extend a mapping and use tools of Unit -Work /DB

Presentation Layer

• Client use APP web in a client and Server.
• The server's side (APP simple templates,JSP )
• The client's side (The API sends and data can be JSON)
• More View and controller with Model

Layer-Controller

• A page, in doc is simple(for simple the page and the client site.)
• Front is when more actions are wanted.

Presentation :Layer -Views

• templates (more client and side but servers 1).
• Transform is when the XML input is more simple
• Two complex for differents - inputs.