Enterprise Software Architecture Patterns

• The content discusses patterns for enterprise software architecture, covering topics from basic principles to distributed applications, database mapping, concurrency, and presentation layers.

Introduction

• The objective involves structuring business applications
• Architecture is defined to be the main application parts and their connections
• Architectural patterns involve important decisions about these parts
• Design patterns should help realize that architecture

Sample business application

• Online store (B2C) with many users, simple business logic, generic web interface, and a database for orders and inventory is a sample application
• Processing house renting is characterized by few users, complex business logic and user interfaces, and a database integrated with external packages for valuations and credit checking
• Small company expenses management is defined by few users, simple logic and scalability, but it also mentions being integrated with complex applications
• A pattern describes a common problem and provides guidelines for solving it on practical foundations
• Solutions can differ on solutions while addressing the same pattern

Layered Architecture

• Layered architecture is a common approach to decompose complex problems, a top layer usually uses services from a bottom layer without a response, bottom layer hides internal levels.
• Benefits include needing to know only the layer below, independent layers that can be replaced with implementations, minimized dependencies, and layer reuse
• Increased risk of cascading changes, performance hits from extra layers, and difficulty in dividing functionality constitute disadvantages
• Presentation is the logic of user application interaction
• Data sources communicate with data providing systems
• Domain logic involves application specific functionality
• The client and the server must decide where layters should be operated for benefits like upgradeability, maintainablity, responsiveness and also offline operation.

Transaction Script

• It is a domain logic pattern for processing, storing/retrieving, invoking other systems, and responding, as is the case in an online store
• It offers a simple procedural model that works well with simplistic data, but disadvantages include incompatibility with complex domain logics
• Domain Model disadvantages include the use of objects to provide suitability for complex data
• Table Module is designed to operate with Record Sets as a compromise between these approaches
• Record is structured around tables, less structured than other OO data, however ideal for things such as .NET

Remote Interfaces to Domain Logic

• Main remote interface forms of HTTP is defined through browsers or web-service formats (HTML, JSON, XML) for message content (universal, easy to deploy), or OO using CORBA, ActiveX, Java RMI (explicit interface)

Web Presentation

• Web Presentation based on web browsers offers universal access and no software installs
• Servers interpret URLs and pass control to applications
• Main structure involves programs such as CGIs or Java Servlets and server pages (HTML and code templates)
• Applying the Model View Controller pattern involves a controller receiving a request, redirecting to a model object, which queries data sources and returns to a controller for the view and displays

View Patterns

• Three patterns for views include Transform, Template, and Two Step
• Template Views define the presentation and are usual for server pages that need easy development but messy code
• Transform Views bases on languages such as XSLT for XML data and can adapt to formats or devices with complexity

Controller Pattern

• In controller patterns, a page controller is an object for each page, while a front controller isolates the responsibilities to process HTTP requests
• Centralized request management is an advantage here

Mapping to Relational DB

• Storing objects in relational DBs faces challenges due to structure differing objects, so object DBs are an alternative
• Mapping for relational DBs can be achieved through Row Data Gateways, Table Data Gateways, Active Records, and Data Mappers
• Gateways are basic patterns mapping classes to database tables
• Patterns contain all the mapping code, but not domain logic
• It should be appropriate for the domain model to be similar to the database schema, combining aspects, although these responsibilities should be seperate
• Data mappers are more complex and flexible, allowing domain objects to be independent from the DB schema

Concurrence

• The topic lists: loading, saving, tracking changes and guaranteeing persistence that avoids loaded objects being concurrently edited in a database
• Unit of Work registers loaded and modified objects; otherwise, domain layer must decide reads and writes

Data Reading

• Mapping classes encapsulate SQL for object-relational mapping, using Identity Map to control what is read
• Mapping data structures faces issues with links (foreign keys) and collections (individual values)
• Identity Fields keep the objects identity to map between databases and objects
• A common relational database has no inheritance mechanism
• Options in mapping is limited to a single table (all classes) or a set of connected tables
• Metadata Mapping facilitates the reuse of mapping tools using files/annotations

Concurrence

• Concurrence is where multiple processes manipulate the same data, but creates issues
• Interaction problems, can be avvoided within a transaction or problems will occur
• Offline-concurrence can span multiple transactions
• You would require things to avoid concurrency mechanism in order not to lose updates or have inconsistent readings

Execution Contexts

• Requests or sessions can be interaction contexts
• Processes offer heavy weight context, and threads are a more lightweight context and transaction coordinate things in DBs
• Isolation is a mechanism to avoid problems, using examples such as operating system memory access or file locks
• Shared data can coordinate concurrently
• Concurrency control can be optimistic or pessimistic

Concurrency Control

• Optimistic locking detects conflicts, while pessimistic locking is focused on a way to prevent any conflicts
• Optimistic locking works best with rare infrequent conflicts and a higher concurrency, with pessimistic locking as default for major conflicts
• Pessimistic locks avoid inconstistent readings through read locks (shared by readers) and write locks (exclusive)
• Pessimistic locking lead to deadlocks, requiring detection/fixes or order blocks

Transactions

• Transactions are the main concurrency control tool, with each applied to DBs, message queues, printers, etc
• Atomicity, consistency, isolation, and persistence are key properties
• System transactions use SQL commands, while business transactions happen at a higher level

Business Transactions

• They span multiple request/responses, and its hard to handle concurrency, or they can lock the system
• Atomicity and persistence are achieved at a user-agreed moment
• Consistency involves the application implementing business rules, with isolation using session controls
• Offline concurrency control is defined as more complex
• Easier to implement and efficient, but detects conflict at the end

Distributed Applications

• Objects from application design become components, with each executed on different nodes
• For distributed objects, differentiate local (multiple simple methods) and remote interfaces (fewer complex methods)
• Minimizing calls and avoiding distributed objects are recommendations
• Local Interfaces for local calls, many methods with simple functionality
• Remote Interfaces for remote calls, methods provide complex functionality, minimise number of calls
• An alternative to that would be scaling up with more application replicas

Distribution Scenarios

• Remote calls are unavoidable between client and server or application server and database
• Remote Facade can group methods of a remote interface
• Data Transfer Objects offer simplified versions of remote objects used to reduced data sent

Putting Into Practice

• Steps for using patterns while developing, using the techincal platform and the domain layer: Transaction Script, Table Module and Domain Model, however Domain Models can require relational databases
• In Transaction Script, the platform uses a database with Row/Table Gateways
• Minimising concurrency problems and corresponding to a system transaction
• Exception needs load data, edit it using Optimistic Offline Lock
• Data access layers uses relational mapping too and a single database table to use multiple classes (inheritance) and class table, use a table per class
• In Table module, the best choice is to use Record Set
• Presentation-Layer can use rich client-side frameworks, and the model can be domain.