Enterprise application architecture

Slides:



Advertisements
Similar presentations
3 Copyright © 2005, Oracle. All rights reserved. Designing J2EE Applications.
Advertisements

Connecting to Databases. relational databases tables and relations accessed using SQL database -specific functionality –transaction processing commit.
And so to Code. Forward, Reverse, and Round-Trip Engineering Forward Engineering Reverse Engineering Round-Trip Engineering.
SOEN 343 Software Design Section H Fall 2006 Dr Greg Butler
Computer Monitoring System for EE Faculty By Yaroslav Ross And Denis Zakrevsky Supervisor: Viktor Kulikov.
Copyright W. Howden1 Lecture 7: Functional and OO Design Descriptions.
Practical Object-Oriented Design with UML 2e Slide 1/1 ©The McGraw-Hill Companies, 2004 PRACTICAL OBJECT-ORIENTED DESIGN WITH UML 2e Chapter 5: Restaurant.
Component-Level Design
From Class Diagrams to Databases. So far we have considered “objects” Objects have attributes Objects have operations Attributes are the things you record.
Satzinger, Jackson, and Burd Object-Orieneted Analysis & Design
SOS OOP Fall 2001 Object Oriented Programming in Java Week 1 Read a design Design a small program Extract a design Run a VAJ program Change that program,
Spring 2009Computer Science Department, TUC-N Object Oriented Methods Architectural Patterns 2.
Data Access Patterns. Motivation Most software systems require persistent data (i.e. data that persists between program executions). In general, distributing.
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
Behavioral Patterns  Behavioral patterns are patterns whose purpose is to facilitate the work of algorithmic calculations and communication between classes.
Design I: Web Application Architecture and Patterns Peter Dolog dolog [at] cs [dot] aau [dot] dk Intelligent Web and Information Systems September.
Domain Logic Patterns  Transaction Script  Domain Model  Table Module  Service Layer.
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.
ABC Insurance Co. Paul Barry Steve Randolph Jing Zhou CSC8490 Database Systems & File Management Dr. Goelman Villanova University August 2, 2004.
An Introduction to Java Chapter 11 Object-Oriented Application Development: Part I.
Pemrograman Web MVC Programming and Design Pattern in PHP 5.
Stored procedures1 Stored procedures and functions Procedures and functions stored in the database.
Database Design and Management CPTG /23/2015Chapter 12 of 38 Functions of a Database Store data Store data School: student records, class schedules,
Object-to-Relational Mapping: The Crossing Chasms Pattern and Implementation Considerations Use of Meta Data in the Java Persistence Layer Presented by.
Architectural Patterns Support Lecture. Software Architecture l Architecture is OVERLOADED System architecture Application architecture l Architecture.
Domain and Persistence Patterns. Fundamental Pattern Types Design Patterns Business Logic Patterns.
JDBC. Java.sql.package The java.sql package contains various interfaces and classes used by the JDBC API. This collection of interfaces and classes enable.
Data Source Patterns.  Table Data Gateway  Row Data Gateway  Active Record  Data Mapper  Unit of Work  Identity Map.
SOEN 343 Software Design Section H Fall 2006 Dr Greg Butler
Elaboration Iteration 3 – Part 3 - Persistence Framework -
Computer Science II 810:062 Section 01 Session 2 - Objects and Responsibilities.
Gerhard Dueck -- CS3013Analysis 1. Gerhard Dueck -- CS3013Analysis 2 Why analysis?  Yield a more precise specification of the requirements.  Introduce.
Practical Object-Oriented Design with UML 2e Slide 1/1 ©The McGraw-Hill Companies, 2004 PRACTICAL OBJECT-ORIENTED DESIGN WITH UML 2e Chapter 6: Restaurant.
Enterprise Java Beans. Contents  Understanding EJBs  Practice Section.
SELECT, IMPLEMENT & USE TODAY’S ADVANCED BUSINESS SYSTEMS
Observer Pattern Context:
Architecture Patterns Design Patterns
Classes and Objects: Encapsulation
Chapter 9 Domain Models.
Recent trends in estimation methodologies
MVC Architecture, Symfony Framework for PHP Web Apps
SOFTWARE DESIGN AND ARCHITECTURE
Classes, Sequence Diagrams and Triangulation
Introduction to Triggers
Server Concepts Dr. Charles W. Kann.
Observer Design Pattern
Architectural Patterns for Interactive Software
Datamining : Refers to extracting or mining knowledge from large amounts of data Applications : Market Analysis Fraud Detection Customer Retention Production.
SQL – Application Persistence Design Patterns
SOEN 343 Software Design Section H Fall 2006 Dr Greg Butler
Lecture Set 14 B new Introduction to Databases - Database Processing: The Connected Model (Using DataReaders)
Chapter 11 Following the Trail; Examining Execution Sequences
Enterprise Architecture Patterns
Lecture 1: Multi-tier Architecture Overview
Web Application Architectures
SOEN 343 Software Design Computer Science and Software Engineering Department Concordia University Fall 2005 Instructor: Patrice Chalin.
SOEN 343 Software Design Computer Science and Software Engineering Department Concordia University Fall 2004 Instructor: Patrice Chalin.
Chapter 22 Object-Oriented Design
Starting Design: Logical Architecture and UML Package Diagrams
Web Application Architectures
Database Design Hacettepe University
SOEN 343 Software Design Computer Science and Software Engineering Department Concordia University Fall 2004 Instructor: Patrice Chalin.
Designing a class.
JDBC Example.
Use Case Analysis – continued
Software Design Lecture : 39.
Web Application Architectures
Software Architecture & Design
Software Design Lecture 5.
INHERITANCE.
Presentation transcript:

Enterprise application architecture Domain Model Enterprise application architecture

Domain Logic Patterns Transaction Script Domain Model Table Module Service Layer

Transaction Script Organizes business logic by procedures where each procedure handles a single request from the presentation

TS: How It Works Each business transaction corresponds to one transaction script Business transaction: Book a hotel room Tasks: check room availability, calculate rates, update the database – all handled in one BookARoom script. Transaction scripts access the database directly Don’t call any logic in the presentation layer Organization Each script is a procedure Related scripts are enclosed in one class Each script is in one class.

TS: Architecture TransactionScript Gateway DB businessTransaction1() sql_query= “ SELECT * FROM table 1…” sql_insert = “INSERT into tablei…” sql_update = “ UPDATE tablei …” sql_delete = “DELETE FROM …” findDataForBusinessTransaction1(sql_query) insertRecordsForBusinessTransaction1(sql_insert, items) updateRecordsForBusinessTransaction2(sql_update, items) … DB

TS: When to use it When the domain logic is very simple When transactions do not have a lot of overlap in functionality

Example Revenue Recognition A contract is signed for one product The revenue of a contract may not be recognized right away. Different types of product may have different revenue recognition schedule Three types of product Word Processor: revenue recognized right away Spreadsheet: 1/3 today, 1/3 in 60 days, 1/3 in 90 days. Database: 1/3 today, 1/3 in 30 days, 1/3 in 60 days. 1 1 * * Product Contract RevenueRecognition Name type date _signed revenue Amount date

TS: Example RecognitionService DatabaseGateway DB calcRecognitions(contract#) recognizedRevenue(contract#, date) createContract(id, revenue, prod_id, date) … DatabaseGateway Sql_findContract = “ SELECT * FROM Contract WHERE id = ?” Sql_findRecogns = “select* from recog Where cid=? and date<?” Sql_insertContract = “INSERT into contract…” findContract(contract#) findRecognitionsFor(contract#, date) insertRecognition(contract#, revenue, date) … DB

Sequence Diagram: test cases :Tester :RecognitionService :DatabaseGateway :Database createContract() insertContract() INSERT into contract … calcRecognitions() insertRecognition() INSERT iinto Recog… insertRecognition() INSERT iinto Recog… insertRecognition() INSERT iinto Recog… recognizedRevenue() findRecognitionsFor() SELECT * FROM …

TS: Example class Gateway { static String findRecogns = “SELECT * FROM revenueRecognition WHERE contract = ? And date <= ?”; static String findContract = “SELECT * FROM contract c, product p WHERE c.id = ? And c.pid = p.id”; public ResultSet findRecognitionsFor(int contrno, Date d) { PreparedStatement s = db.prepareStatement(findRecongs); s.setInt(1, contrno); s.setDate(2, d); ResultSet result = s.executeQuery(); return result; } public ResultSet findContract(int contrno) { PreparedStatement s = db.prepareStatement(findContract);

TS: Example class RecognitionService { private Gateway gw = new Gateway(); public Money recognizedRevenue(int contrno, Date d) { Money Result = Money.dollar(0); ResultSet rs = gw.findRecognitionsFor(contrno, d); while (rs.next()) { result = result.add(rs.getBigDecimal(“amount”)); } return result; public void calculateRevenueRecognitions(int contrno) { ResultSet contrs = gw.findContract(contrno); totalRevenue = contrs.getBigDecimal(“revenue”); date = contrs.getDate(“date_signed”); type = contrs.getChar(“type”); if (type == ‘S’) { gw.insertRecognition(contrno, totalRevenue/3, date); gw.insertRecognition(contrno, totalRevenue/3, date+60); gw.insertRecognition(contrno, totalRevenue/3, date+90); } else if (type = ‘W’) { gw.insertRecognition(contrno, totalRevenue, date); } else if (type == ‘D’ { ...

Domain Model An object model of the domain that incorporates both behavior and data

DM: Revenue Recognition 1 * Contract RevenueRecognition date _signed revenue Amount date recognizedRevenue(date) calculateRecognitions() isRecognizableBy(date) * 1 Product DB Name type calcRecognitions(contrct) Three-way RecognitionStrategy * 1 RecognitionStrategy Complete RecognitionStrategy calcRecognitions(contrct)

DM: Example class RevenueRecognition { private Money amount; private Date date; public RevenueRecognition(Money amnt, Date d) {...} public Money getAmount() { return amount; } public boolean isRecognizableBy(Date date) { return this.date.before(date) || this.date.equals(date); ... class Contract { private List revenueRecognitions = new ArrayList(); public Money recognizedRevenue(Date date) { Money result = Money.dollar(0); Iterator it = revenueRecognitions.iterator(); while (it.hasNext()} { RevenueRecognition r = (RevenueRecognition)it.next(); if (r.isRecognizableBy(date)) result = result.add(r.getAmount()); return result;

DM: Example class RevenueRecognition { private Money amount; private Date date; public RevenueRecognition(Money amnt, Date d) {...} public Money getAmount() { return amount; } public boolean isRecognizableBy(Date date) { return this.date.before(date) || this.date.equals(date); ... class Contract { private List revenueRecognitions = new ArrayList(); public Money recognizedRevenue(Date date) { Money result = Money.dollar(0); Iterator it = revenueRecognitions.iterator(); while (it.hasNext()} { RevenueRecognition r = (RevenueRecognition)it.next(); if (r.isRecognizableBy(date)) result = result.add(r.getAmount()); return result;

DM: Example class Contract { private Product product; private Money amount; private Date dateSigned; private long id; public Contract(Product p, Money amnt, Date d) {...} public void addRecognition(RevenueRecognition rr) { revenueRecognitions.add(rr); } public Date getDateSigned() { return dateSigned; public void calcRecognitions() { product.calcRecognitions(this); ... interface RecognitionStrategy { public void calcRevenueRecognitions(Contract c);

DM: Example class CompleteRecognitionStrategy implements ... { public void calcRevenueRecognitions(Contract c) { c.addRecognition(new RevenueRecognition( c.getAmount(), c.getDateSigned()); } class ThreeWayRecognitionStrategy implements ... { private int firstRecognitionOffset; private int secondRecognitionOffset; public ThreeWayRecognitionStrategy(int offset1, int offset2) { this.firstRecognitionOffset = offset1; this.secondRecognitionOffset = offset2; c.getAmount()/3, c.getDateSigned()); c.getAmount()/3, c.getDateSigned()+offset1); c.getAmount()/3, c.getDateSigned()+offset2); ... }

DM: Example class Product { private String name; private RecognitionStrategy recogStrategy; public Product(String name, RecognitionStrategy rs) { this.name = name; this.recogStrategy = rs; } public void calcRecognitions(Contract c) { recogStrategy.calcRecognitions(c); public static Product newWordProcessor(String name) { return new Product(name, new CompleteRecognitionStrategy()); public static Product newSpreadsheet(String name) { new ThreeWayRecognitionStrategy(60, 90)); public static Product newDatabase(String name) { new ThreeWayRecognitionStrategy(30, 60));

DM: Example class Tester { public static void main(String[] args) { Product word = Product.newWordProcessor(“IntelWord”); Product calc = Product.newSpreadsheet(“calc II”); Product db = Product.newDatabse(“DB IV”); Date today = System.today(); Contract c1 = new Contract(word, 300000, today); c1.calcRecognitions(); Contract c2 = new Contract(calc, 24000, today); c2.calcRecognitions(); // sequence diagram – next slide Contract c3 = new Contract(db, 540000, today); c3.calcRecognitions(); System.out.println(c1.recognizedRevenue(today + 10)); System.out.println(c2.recognizedRevenue(today + 70)); System.out.println(c3.recognizedRevenue(today + 80)); }

recogStrategy:RecognitionStrategy DM: Sequence Diagram: c2.calcRecognitions() :Tester c2.:Contract recogStrategy:RecognitionStrategy product:Product calcRecognitions() calcRecognitions(c2) calcRecognitions(c2) Mount = getAmount() (amount/3, date) date = getDateSigned() rr1:RevenueRecognition addRecognition(rr1) (amount/3, date + 60) rr2:RevenueRecognition addRecognition(rr2) (amount/3, date + 90) rr3:RevenueRecognition addRecognition(rr3)

DM: Sequence Diagram: c2.recognizedRevenue() :Tester c2.:Contract rr[0]:RevenueRecognition rr[1]:RevenueRecognition rr[2]:RevenueRecognition recognizedRevenue(date) isRecognizableBy(date) getAmount() isRecognizableBy(date) getAmount() isRecognizableBy(date) return result

Table Module A single instance that handles the business logic for all rows in a database table or view Each module is responsible for all the CRUD operations on the corresponding table. No other modules are supposed to CRUD directly on the table Each module also includes business logic that is tightly related to the table.

TM: Architecture TableModule_1 Table_1 CRUD operations on Table_1 Business Logic related to Table_1 Attributes TableModule_2 Table_2 CRUD operations on Table_2 Business Logic related to Table_2 Attributes Database TableModule_n Table_n CRUD operations on Table_n Business Logic related to Table_n Attributes

TM: Example - Tables Contract RevenueRecognition Id: Number Id: Number dateSigned: Date revenue: Number prod_id: Number (FK) Id: Number amount: Number date: Date c_id: Number (FK) Product Id: Number name: String type: String

TM: Example - Modules Contract RevenueRecognition Insert(cid, revenue, prod_id, date) calculateRecognitions(c_id) Insert(c_id, amount, date) recognizedRevenue(c_id, date) Product getProductType(prod_id) DB

TM: Sequence Diagram: calcRecognitions() :Tester :RevenueRecognition :Contract calcRecognitions(cid) :Product getContract(id) DB contract:ResultSet SELECT getProductID() getProductType(pid) SELECT getRevenue() getDateSigned() insert(cid, revenue/3, date) INSERT insert(cid, revenue/3, date+60) INSERT insert(cid, revenue/3 date+90) INSERT return result

recognitions:ResultSet TM: Sequence Diagram: recognizedRevenue() :Tester :RevenueRecognition :Contract recognizedRevenue(c_id, date) getRecognitions(c_id, date) DB recognitions:ResultSet SELECT getAmount() getAmount() getAmount() return result

Service Layer Defines an application’s boundary with a layer of services that establishes a set of available operations and coordinates the application’s response in each operation. Two type of business logic Domain logic: pure logic of the business domain E.g., calculating revenue recognitions of a contract Application logic: application responsibilities E.g., notifying administrators and integrated applications, of revenue recognition calculations

TM: Example - Modules Service Layer Domain Model Integration Gateways Data Loader User Interfaces Service Layer Domain Model DB

SL: Architecture Domain logic: Domain model layer Application logic: Service layer Service layer: Operation Scripts – A set of classes that implement application logic but delegate to domain model classes for domain logic. Clients interact with the operation scripts Operation scripts for a subject area are encapsulated in a class named SubjectService.

SL: Services and Operations Determined by the needs of clients Derived from use case models Data validation CRUD operations on domain objects Notification of people or other integrated applications All responses must be coordinated and transacted automatically by the service layer

SL: When to Use It When there are many different kinds of clients When the response may involve application logic that needs to be transacted across multiple transactional resources

SL: Example Revenue Recognition New requirements: once revenue recognitions are calculated, it must Email a notification to contract administrators Publish a message to notify other integrated applications

SL: Example ApplicationService IntegrationGateway EmailGateway getEmailGateway(): EmailGateway getIntegrationGateway(): IntegrationGateway IntegrationGateway EmailGateway publishRevenueRecogs(contract) sendEmail(toAddr, subj, body) RecognitionService calcRevenueRecogs(contr#) recognizedRevenue(contr#, date) Domain Model Contract RevenueRecognition Product

SL: Example class RecognitionService extends ApplicationService { public void calcRevenueRecogs(contractNo) { Transaction trans = Transaction.getNewTransaction(); trans.begin(); // delegate to domain objects Contract contract = Contract.getContract(contractNo); contract.calcRecognitions(); Contract c2 = new Contract(calc, 24000, today); // interact with transactional sources getEmailGateway().sendEmail(contract.getAdminEmail(), “RE: contract revenue recognitions”, contract.getId() +”Recognitions calculated”); getIntegrationGateway().publishRevenueRecogs(contract); trans.commit(); }

Domain Logic: Summary Transaction Script Domain Model Table Module One script per user request/action Good for simple, no-overlapping business logic Domain Model A set of interrelated objects for business logic Good for application with complex business logic Table Module A module for the CRUD operations and business logic for a table in DB Compromise between Transaction Script and Domain Model Service Layer Application logic is separated into a new layer from domain logic Good for applications that have complex application logic – interacting with multiple transactional resources