Design Patterns - Enterprise Patterns (part 2)

fabio.armani

Overview

•  Analysis pa4erns •  Architectural pa4erns •  Design pa4erns •  Enterprise pa4erns •  GRASP pa4erns •  ImplementaAon pa4erns •  J2EE Core pa4erns •  SCM pa4erns

ENTERPRISE PATTERN

Enterprise Pa4erns •  Pa4erns of Enterprise ApplicaAon Architecture •  Core J2EE Pa4erns •  IntegraAon Pa4erns

Enterprise Pa4erns > books

Core J2EE Pa4erns •  PresentaAon Tier •  Business Tier •  IntegraAon Tier

Core J2EE Pa4erns •  PresentaAon Tier

–  ApplicaAon Controller –  Composite View –  Context Object –  Dispatcher View –  Front Controller –  IntercepAng Filter –  Service To Worker –  View Helper

Core J2EE Pa4erns •  Business Tier

–  Data Transfer Object (DTO) –  Business Object (BO) –  Service Locator –  ApplicaAon Service

•  IntegraAon Tier –  Data Access Object (DAO) –  Domain Store –  Web Service Broker

Core J2EE Pa4erns •  Business Tier

–  Data Transfer Object (DTO) –  Business Object (BO) –  Service Locator –  ApplicaAon Service

•  IntegraAon Tier –  Data Access Object (DAO) –  Domain Store –  Web Service Broker

PresentaAon Tier Pa4ern

•  Front Controller •  View Helper •  Composite View •  Dispatcher View

Business Tier Pa4ern •  Data Transfer Object •  Business Object •  Service Locator •  ApplicaAon Service •  Business Delegate •  Value List Handler •  Session Facade •  Composite EnAty •  Transfer Object •  Transfer Object Assembler

Business Tier Pa4ern •  Data Transfer Object •  Business Object •  Service Locator •  ApplicaAon Service •  Business Delegate •  Value List Handler •  Session Facade •  Composite En7ty •  Transfer Object •  Transfer Object Assembler

Ejb Pattern

DATA TRANSFER OBJECT PoEAA -‐ pag. 117

DATA TRANSFER

Data Transfer Object (DTO)

Descrizione •  Il DTO (Data Transfer Object ) è un pa4ern che risulta essere

molto uAle lavorando in applicazioni Apicamente distribuite, in cui la maggior parte delle chiamate e delle invocazioni è fa4a in maniera remota (macchine diverse).


Descrizione •  L' Ogge4o di Trasferimento DaA o Data Transfer Object (in

sigla DTO) è un design pa4ern usato per trasferire daA tra so4osistemi di un'applicazione so\ware.

•  I DTO sono spesso usaA in congiunzione con gli ogge] accesso daA per recuperare i sudde] da una base di daA.

•  La differenza tra gli ogge] di trasferimento daA e gli ogge] business o gli ogge] d'accesso daA è che un DTO non ha alcun comportamento se non di archiviare e recuperare i suoi daA.


Presenta<on

Business

Data Access


Scopo •  Una buona organizzazione di una archite4ura enterprise è

cosAtuita normalmente di un straAficazione basata almeno sui seguenA livelli: –  strato client applicaAvo (esempio le ac7ons di una applicazione

Struts), –  strato client di comunicazione con il server (BD), –  strato server di session façade, –  uno o più straA applicaAvi di sessione, strato data model (en7ty

beans).


Scopo


Soluzione


Scopo •  In una tradizionale archite4ura EJB, un DTO ha un duplice

scopo: –  porre riparo al problema derivante dal fa4o che gli en7ty beans pre-‐

ejb 3.0 (in J2EE) non sono serializzabili; –  definire implicitamente una fase di assemblaggio dove tu] i daA che

devono essere usaA da una view sono prelevaA e marshallizza7 nei DTO prima di resAtuire il controllo al presenta7on layer.


Problema •  Si vogliono trasferire molA daA lungo più layers di

un’applicazione. In parAcolare, si vuole che il client possa accedere ai componenA di diversi layer per recuperare o aggiornare daA.

•  Inoltre, in uno scenario di invocazione remota, sorge il problema del network overhead a causa delle numerose chiamate al server, sia per il recupero dei daA sia per il salvataggio degli stessi.


Soluzione •  UAlizzare un Data Transfer Object per incapsulare i daA di

business. Una singola chiamata a un metodo è usata per inviare e recuperare il Transfer Object.

•  Quando il cliente richiede dei daA di business, il DTO viene istanziato e popolato con i rispe]vi valori e poi passato al client.

•  Esso viaggia lungo tu] gli straA dell’applicazione.


Presenta<on

Business

Data Access

DTO

DTO


Soluzione


CaraAeris<che •  Il DTO è un ogge4o dotato di cara4erisAche parAcolari:

–  è serializzabile, –  conAene solo proprietà e –  non ha all’interno alcuna logica di business.

•  Come dice lo stesso nome del pa4ern è quindi un oggeHo che serve per trasferire dei da7.

•  In uno scenario di invocazione remota, fare numerose chiamate al server per o4enere dei daA causa un network overhead non indifferente; per questo moAvo bisogna cercare di minimizzare queste chiamate al server e il DTO ci aiuta.


StruAura


Esempio: interazione senza uAlizzo DTO


Esempio: interazione con server mediante DTO


Esempio •  Possiamo infa] inserire nel DTO tu4e le informazioni che

vogliamo farci resAtuire dal server in modo tale da fare una sola chiamata.

•  Stesso ragionamento se vogliamo salvare delle informazioni, infa] fare più chiamate per il salvataggio è oneroso, invece farne una sola passando i daA da salvare nel DTO è più efficiente.


Implementazione •  Vi sono due approcci base per la costruzione del DTO:

–  Creare un DTO per ogni enAtà nel modello dei daA. Questo approccio consente una completa trasposizione del modello e quindi una completa interazione con le enAtà in o]ca di recupero informazioni o salvataggio.

–  Creare un DTO thin, inserendo solo le informazioni di cui abbiamo bisogno. Questo ha pro e contro, infa] un vantaggio è sicuramente l’aumento delle prestazioni visto che i daA da serializzare e deserializzare saranno di meno, tu4avia lo svantaggio è che nel momento in cui vogliamo un campo in più dovremmo modificare lato codice il DTO con tu4e le conseguenze che ne derivano.


Implementazione •  Considerando che un proge4o è sogge4o a conAnui

cambiamenA nei requisiA, probabilmente se non ci sono problemi di prestazioni, la prima scelta è quella più opportuna.

•  Ecco un esempio, in Java, di un DTO.


Implementazione •  Considerando che un proge4o è sogge4o a conAnui

cambiamenA nei requisiA, probabilmente se non ci sono problemi di prestazioni, la prima scelta è quella più opportuna.

•  Ecco un esempio, in Java, di un DTO.

Data Transfer Object (DTO) public class StudenteDTO implements Serializable {

private int age; private String nome; private String cognome;

public int getAge() { return age; } public void setAge(int age) { this.age = age; } public String getNome() { return nome; } public void setNome(String nome) { this.nome = nome; } public String getCognome() { return cognome; } public void setCognome(String cognome) { this.cognome = cognome; }

}


Implementazione •  Come potete notare, dal punto di vista pre4amente di codice

Java, un DTO è un POJO che implementa l’interfaccia Serializable.

Data Transfer Object (DTO) // esegue una operazione di ricerca per chiave primaria sulla entità articolo // e ricava la interfaccia locale dell'entity bean public ArticleDTO articleFindByPrimaryKey(String id) throws EJBException { try { ArticleLocal articleLocal = articleLocalHome.findByPrimaryKey(id)); Hashtable articleDTO = new hashtable(); articleDTO.put("articleName", articleLocal.getName()); articleDTO.put("abstractText", articleLocal.getAbstractText()); articleDTO.put("notes", articleLocal.getNotes()); articleDTO.put("title", articleLocal.getTitle()); articleDTO.put("subTitle", articleLocal.getSubTitle()); articleDTO.put("introduction", articleLocal.getIntroducion()); articleDTO.put("body", articleLocal.getBody()); articleDTO.put("id", articleLocal.getId()); articleDTO.put("status", articleLocal.getStatus()); return articleDTO; } catch (ObjectNotFoundException onfe) { logger.debug("nessun articolo trovato con Id=" + id); return null; } catch (Exception e) { throw new EJBException(e.getMessage()); } }


Sequence diagram



Conseguenze •  Le conseguenze che derivano dall’uAlizzo dei Data Transfer

Objects sono: –  riduzione del traffico di rete –  semplificazione delle interfacce remote –  riduzione del codice duplicato –  trasferimento di una maggior quanAtà di daA in meno chiamate remote

BUSINESS OBJECT PoEAA -‐ pag. 117

BUSINESS OBJECT

Business Object

Problema •  Si ha un’applicazione con un modello conce4uale complesso,

dotato di una logica di business sofisAcata, con regole di validazione complesse e ogge] complessi correlaA.

•  Si vuole separare lo stato di business e il relaAvo comportamento dal resto dell’applicazione, incrementandone così coesione e riusabilità.

•  Inoltre, si vuole evitare la duplicazione del codice.

Business Object

Data Access Object

Data Access Object

Service

Service

Service

Business Tier Integration Tier

I servizi del business tier accedono direttamente ai sistemi legacy, o attraverso dei data access object

DBMS

Business Object

Data Access Object

Data Access Object

Service

Service

Service


DBMS

Utilizzare Business Object che incapsulano dati e logica e che delegano ad altri componenti la loro persistenza

Business Object

Data Access Object

Data Access Object

Service

Service

Service


BO

BO

Utilizzare Business Object che incapsulano dati e logica e che delegano ad altri componenti la loro persistenza

DBMS

Business Object

Soluzione •  Si uAlizza un insieme di Business Objects per separare i daA di

business dalla logica di business usando un object model. •  Si implementano un insieme di classi che rappresentano un

ulteriore strato all’interno dell’applicazione che incapsulino i daA di business, così da separare la logica di business dai daA di business.

Business Object

Soluzione •  Viene creato un layer di Business Object che rappresentano il

domain model •  Perme4e di separare il modello di daA dalla sua persistenza •  Aumenta la riusabilità del codice

Business Object: strategie

Implementazioni Apiche: •  BO come POJO, con un meccanismo di persistenza Apo:

•  Data Access Object à Integra7on Tier PaHern •  JDO •  Tool di persistenza -‐ ORM (Hibernate, ...)

•  BO come Enterprise Java Bean (EJB) •  CMP •  BMP

Business Object

Conseguenze •  Tra le conseguenze che derivano dall’uAlizzo di tale pa4ern

abbiamo: –  evita la duplicazione del codice e favorisce la manutenibilità dello

stesso –  separa la logica di persistenza dalla logica di business –  promuove un’archite4ura di Apo service-‐oriented –  aggiunge un ulteriore strato di indirezione

APPLICATION SERVICE PoEAA -‐ pag. 117

ApplicaAon Service

Spesso è difficile esprimere tu4a la logica applicaAva in termini di business object

•  use-‐case complessi e/o arAcolaA •  aumenta l’accoppiamento degli ogge] del domain model

•  difficile ed improprio gesAre nei BO problemaAche di transazionalità o sicurezza

ApplicaAon Service

Client ApplicationService- accedes

BusinessObject

DataAccessObject

Service

- uses

0..*

- uses

0..*

- uses

0..*ServiceFacade «Pojo»Helper

Centralizza l’invocazione della logica di business in uno strato di servizi

ApplicaAon Service

•  Centralizza la logica riusabile, evitando duplicazioni di codice

•  Può gesAre problemaAche di transazionalità e sicurezza

•  Introduce un nuovo livello (Service Layer) all’interno del Business Tier

ApplicaAon Service

E’ la base per la creazione di un Service Layer

Integration Layer

Domain Model (in Business Layer)

Bo

Bo

Service Layer (in Business Layer)

Service

Service PresentaAon

Batch

ApplicaAon Service

Command Strategy

Client

ApplicationService

ServiceFacade «Pojo»Helper

ApplicationController- invokes

CommandFactory

Command

+ execute ( )

- uses

- invokes

- creates

- invokes

SERVICE LOCATOR PoEAA -‐ pag. 117

Service Locator

L’accesso ai componenA di business può essere complesso

Client

Ejb

Anche utilizzando JNDI il codice necessario ad effettuare queste operazioni è poco leggibile e duplicato

POJO

Jms Service

Service Locator

Client

Ejb

Db ServiceLocator

Nasconde la complessità di lookup e creazione Fornisce una modalità di accesso uniforme Memorizza in cache i dati

Service

Service Locator

Client «Singleton»ServiceLocator- uses

1

1..*

TargetService

- _looksup

- accesses

Cache

- mantains

- caches

InitialContext- creates/uses

RegistryService

- refers

- resolves

Una implementazione tipica

BUSINESS DELEGATE PoEAA -‐ pag. 117

Business Delegate

Quando accedo ad un client ad un servizio remoto (Ejb, Jms) il codice di connessione ed invocazione è complesso e mescolato al codice applicaAvo

Client Session Ejb

Business Delegate

Un Business Delegate incapsula l’accesso ad un servizio remoto, nascondendo i de4agli dell’implementazione di lookup e del meccanismo di accesso.

–  Riduce l’accoppiamento tra componenA (il client non conosce la tecnologia del servizio remoto)

–  Traduce le eccezioni che arrivano dal servizio remoto –  Può implementare meccanismi di recovery e caching

Business Delegate

Client«Pojo»

BusinessDelegate

«Singleton»ServiceLocator

- uses

- accesses«interface»

BusinessService

EjbService JmsService

- accesses

looksup

Un’archite4ura per il BT

Dati

BO

BO

BO

BO

Client

Client

Servizio

Servizio

Delegate

Delegate

Service Locator

IntegraAon Tier Pa4ern

•  Data Access Object •  Domain Store •  Service Ac7vator •  Web Service Broker

DATA ACCESS OBJECT PoEAA -‐ pag. 117

DATA ACCESS

Data Access Object (DAO)

DataAccessObject

BusinessObject DataPersistence

ValueObject

encaplsulates uses

creates/uses obtains/modifies


Problema •  Si vuole separare l’accesso ai daA dal resto dell’applicazione,

al fine di ”proteggere” l’applicazione da eventuali modifiche allo strato di persistenza, come ad esempio il cambiamento da un database a un altro. Quello che si vuole è implementare meccanismi per accedere e manipolare i daA in una base di daA riuscendo però a disaccoppiare lo strato di persistenza dal resto dell’applicazione.

•  Inoltre, si vuole fornire un’API uniforme per un meccanismo di persistenza che sia ada4a a diversi Api di sorgenA di daA (RDBMS, LDAP, OODB, ...)


Problema •  E' evidente come una modifica del disposiAvo di persistenza

implichi modifiche al codice di tu] gli EJB che vi accedono. •  Per confronto si propone lo stesso metodo che uAlizza una

classe DAO che incapsula l'uAlizzo di JDBC :


Soluzione •  Si usa uno strato intermedio, il Data Access Object (DAO), per

astrarre e incapsulare tu] gli accessi al database. Il Data Access Object gesAsce le connessioni con il database per caricare e salvare i daA.

•  Tale strato è cosAtuito da un insieme di classi dotato di metodi che si occupano di gesAre qualsiasi interazione con la sorgente daA.


Scopo •  L'intento del pa4ern DAO (Data Access Object) è di

disaccoppiare la logica di business dalla logica di accesso ai daA.

•  Questo si o]ene spostando la logica di accesso ai daA dai componenA di business ad una classe DAO rendendo gli EJB indipendenA dalla natura del disposiAvo di persistenza.

•  Questo approccio garanAsce che un eventuale cambiamento del disposiAvo di persistenza non comporA modifiche sui componenA di business.


Funzionamento •  L'idea del pa4ern DAO si basa sulla possibilità di concentrare

il codice per l'accesso al sistema di persistenza in una classe che si occupa di gesAre la logica di accesso ai daA.

•  Ad esempio nel caso di un accesso a DBMS si inserisce nel DAO tu4o il codice per effe4uare operazioni sulla base daA, nascondendo le problemaAche JDBC.

•  Di seguito si riporta il codice di un metodo di business che reperisce i daA dire4amente dal DBMS :

Accesso dire4o a DBMS

import javax.sql.*; import java.sql.* ; . . . public void doSomething(String key) throws SQLException { InitialContext ic = new InitialContext(); DataSource ds = (DataSource) ic.lookup("jdbc/MyDB"); Connection con = ds.getConnection(); String selectStatement = "SELECT NAME FROM ACCOUNT where ID=?"; prepStmt =con.prepareStatement(selectStatement); prepStmt.setString(1, key); ResultSet result = prepStmt.executeQuery(); if (result.next()) { this.name = result.getString(1); } else { throw new SQLException("Name NOT found !"); } }


Implementazione

import org.openware.dao.*; public void doSomething (String key) throws MyDataAccessException { MyObjectValue result = this.dao.readAccount(key); if (result != null) { this.name = result.getName(); } else { throw new MyDataAccessException("Name NOT found !"); } }


Soluzione •  A parità di funzionalità offerte, l'uAlizzo della classe DAO

rende indipendente l'EJB dal DBMS e riuAlizzabile per qualsiasi mezzo di persistenza accessibile con la medesima interfaccia DAO.


StruAura •  Il DAO viene invocato dal Business Object e si occupa di

effe4uare l'accesso ai daA resAtuendoli all'applicazione. •  Le informazioni che il DAO resAtuisce al Business Object sono

ogge] generici ( indipendenA dal disposiAvo di persistenza ) e le eventuali eccezioni specifiche della risorsa daA sono mascherate ( wrapped ) in eccezioni generiche di Apo applicaAvo.


StruAura

ValueObject

BusinessObject DataAccessObject DataPersistence

creates/uses

obtains/modifies

uses encaplsulates




Implementazione •  Il client crea l'EJB invocando il metodo create sull'istanza della

Home Interface recuperata mediante le operazioni di lookup e narrow.

Account account = accountHome.create("007", "Java Earl", ”[email protected]", 0);


Class Diagram

org.openware.paAern.dao.MyDao

org.openware.paAern.dao.MyDaoImpl

...paAern.excep<on.DAOExpe<on

java.lang.Excep<on


Implementazione •  Il container invoca il metodo ejbCreate che si avvale

dell'istanza dao creata nel metodo setEntityContext :

public void setEntityContext(EntityContext ctx) { . . . try { this.dao = new MyDaoImpl("java:comp/env/jdbc/OpenwareDataBase"); } catch (NamingException e) { . . . } }


Implementazione •  Allo sviluppatore dell'EJB è reso trasparente l'accesso alla

tabella del DBMS mediante JDBC, infa] si limita a chiamare il metodo insertAccount del DAO.

•  Si noA come nel codice del bean non si ha nessun riferimento ai package sql (java.sql e javax.sql) bensì vengono importate l'interfaccia MyDao, la classe concreta MyDaoImpl e l'eccezione DAOException.

Data Access Object (DAO) Import org.openware.pattern.dao.MyDao; import org.openware.pattern.dao.MyDaoImpl; import org.openware.pattern.exception.DAOException; public AccountPK ejbCreate(String id, String name, String address, double balance) throws CreateException { . . . try { // Use DAO to insert account into the underlaying layer AccountPK pk = new AccountPK(id); this.dao.insertAccount(pk, name, address, balance); this.name = name; this.email = address; this.balance = balance; return pk; } catch (DAOException e) { . . . } }

Data Access Object (DAO) public class MyDaoImpl implements MyDao { public int insertAccount(AccountPK pk, String name, String address, double balance) throws DAOException { Connection con = null; PreparedStatement stmt = null; try { con = dataSource.getConnection(); stmt = con.prepareStatement( "INSERT INTO OPWR_ACCOUNT(ID, NAME, ADDRESS, BALANCE) VALUES (?, ?, ?, ?)"); stmt.setString(1, pk.id); stmt.setString(2, name); stmt.setString(3, address); stmt.setDouble(4, balance); int res = stmt.executeUpdate(); return res; } catch(SQLException sqle) { throw new DAOException(sqle.getMessage()); } finally { closeResources(con, stmt, null); } }


Il metodo insertAccount effe4ua l'accesso fisico alla tabella del DBMS mediante JDBC.


Il metodo insertAccount effe4ua l'accesso fisico alla tabella del DBMS mediante JDBC.


Le SQLException vengano "wrappate" in eccezioni applicaAve DaoException.


Implementazione •  Il funzionamento degli altri metodi è analogo a quanto

appena spiegato :

Client EJB AccountDAO SQL

create ejbCreate insertAccount INSERT



appena spiegato :



findByPrimaryKey ejbFindByPrimaryKey accountExists SELECT



appena spiegato :




remove ejbRemove deleteAccount REMOVE



appena spiegato :





load ejbLoad readAccount SELECT



appena spiegato :





load ejbLoad readAccount SELECT

store ejbStore updateAccount UPDATE


Un caso d’uso •  Il pa4ern DAO si inserisce in quei contesA in cui un accesso a

componenA di persistenza deve essere reso trasparente all'applicazione.

•  L'esempio proposto rappresenta il caso di una banca che ha la necessità di memorizzare le informazioni del conto corrente utente su un disposiAvo di persistenza.

•  In una situazione di questo Apo è uAle che gli EJB si interfaccino con il DB con un layer di disaccoppiamento garanAto dal DAO.


Un caso d’uso

org.openware.pattern.ejb.session

org.openware.pattern.ejb.entity

org.openware.pattern.dao PersistenceModule



Conseguenze •  Alcune delle conseguenze dell’applicazione di tale pa4ern

sono: –  abilita la trasparenza –  rende possibile una più facile migrazione verso altri storage engine

–  fornisce una visione object-‐oriented e incapsula gli schemi del database

–  organizza tu4o il codice che si occupa dell’accesso ai daA in un layer separato

Data Access Object

Nelle applicazioni J2ee è spesso necessario integrare o migrare sistemi legacy operanA con diverse tecnologie

•  RDBMS, OODB •  LDAP •  Flat files, XML, ... •  CICS, IMS, ...

Codificare l’integrazione con quesA sistemi nel codice applicaAvo o nei business object rende l’applicazione poco flessibile, espandibile e riusabile

Data Access Object

DB Data Access

Object

Data Access Object

Integration Tier

LDAP

Client

Client

Utilizzare un Data Access Object (DAO) che mascheri e incapsuli la logica di accesso ai dati

Data Access Object

•  E’ applicabile in ogni occasione in cui l’applicazione debba accedere a dei daA

•  Disaccoppia la logica di business da quella di persistenza •  Facilita, dopo l’integrazione, il processo di migrazione •  Strategie Apiche di uAlizzo:

•  con business object POJO •  in combinazione con EJB BMP •  per l’integrazione con ambienA parAcolari (IMS, LDAP, file)

Data Access Object: responsabilità

•  Crea una connessione al data source •  Non gesAsce dire4amente la transazione ma è in grado di partecipare ad una transazione

•  E’ responsabile del marshalling e unmarshalling tra ogge] di business e daA persistenA

Data Access Object: implementazione

Client DataAccessObject

+ create ( )+ read ( )+ update ( )+ delete ( )

DataSource

«TransferObject»Data

ResultSet

- uses - accesses

- creates- uses

- creates- creates/uses

Data Access Object: implementazione

Client DAOFactory

+ getDaoAlpha ( )+ getDaoBeta ( )+ getDaoGamma ( )

MySqlDAOFactory


HypersonicDAOFactory


- uses

- delegates

- delegates

MySqlAlphaDAO

HypersonicSqlAlphaDao

- creates

- uses

- creates

- uses

Passato, Presente e Futuro

... dei paAern ... •  Studio delle applicazioni esistenA •  Best prac7ce per la proge4azione •  Model Driven Architecture (MDA) e pa4ern

Referenze

hHp://www.corej2eepaHerns.com

Alur, Crupi, Malks, Core J2ee Patterns – Best Practices and Design Strategies, 2nd edition, Prentice Hall, 2003

Software

Design Patterns - Enterprise Patterns (part 2)