1
Domain Model In ottica SOA
Di Ricci Gian MariaIV Workshop DotNetMarche
DotNetMarche
2
Cosa è SOA• A set of components witch can be invoked, and whose interface
descriptions can be published and discovered (W3C consortium)• SOA is an architectural style whose goal is to achieve loose coupling
among interacting software agents (Hao He)• SOA is kind of an IT manager’s holy grail, in witch software components
can be exposed as services on the network, and,so, can be reused time and time again for different applications and purposes (Preston Gralla)
• The polices, practices, frameworks that enable application functionality to be provided and consumed as sets of services published at a granularity relevant to the service consumer. Services can be invoked, published and discovered, and are abstracted away from the implementation using a single, standards based form of interface. (David Sprott and Lawrence Wilkes)
• The message is the medium (Don Box)
3
SOA – Service Oriented Architecture
• SOA non significa aggiungere un webservice ad una applicazione esistente
Applicazione Web Service
• Una struttura di questo tipo non è funzionale e sicuramente non è architettata per funzionalità SOA
4
SOA – Service Oriented Architecture
• Un applicativo SOA, come dice il nome stesso è architettato per essere usato come “Servizio”
• Il termine Web Service indica solamente una tecnologia che facilita la realizzazione di servizi, ma non riguarda la parte architetturale
• Si possono fare servizi anche senza la tecnologia Web Service
• Un buon servizio viene pensato e progettato per soddisfare certi requisiti, non tutti gli applicativi possono essere convertiti in servizio “on the fly”
5
SOA vs DD
• Una progettazione DDD come si pone rispetto all’architettura SOA?
Architettura SOA
Domain Driven Design
6
Layering
• Uno dei concetti base di un architettura SOA è il loosely coupling o “basso accoppiamento”
• Una applicazione senza chiara suddivisione tra aree, parti, o funzionalità è difficilmente esponibile all’esterno come servizio
7
Layering
• Una chiara suddivisione del software in layer facilita l’esposizione di funzionalità tramite un servizio
WS
UI (Presentation)
BL (Business Logic)
DAL (Data Access Layer)
8
Layering
• Nella realtà la suddivisione in layer è solitamente più complessa dei soli tre layer precedenti
UI ComponentsUI Process components
Service interface
Business workflow Business components Business entities
Data Access Logic Components Service Agents
Security
Operational
Managem
ent
Comm
unication
9
Layering e Domain Driven Design
• Una architettura DDD individua ed isola per definizione la parte “importante” della logica di dominio facilitando la separazione tra logiche di presentazione, applicazione, accesso ai dati etc.
DOMAIN
UI
DB
APP
SERVIZIO
10
SOA è elaborazione distribuita• Una invocazione di una funzione in un servizio è sempre
associata ad una chiamata remota• La distanza tra l’utilizzatore ed un servizio è nel caso
migliore di un processo, ma normalmente si ha una chiamata tra macchine separate da reti locali o internet
11
Coarse grained vs fine grained
• La modellazione OO favorisce la creazione di interfacce Fine Grained molto flessibili
• Le interfacce Fine Grained hanno però lo svantaggio di aumentare il numero di remote call per svolgere una data operazione.
Crea Ordine
SetData
AddLine
AddLine
AddLine
12
Coarse grained vs Fine grained
• Un interfaccia di un servizio deve invece assumere una struttura Coarse Grained
• Una struttura Coarse Grained diminuisce il numero di chiamate ad un servizio ottimizzando le prestazioni.
Crea Ordine(DateTime, IList<LineeOrdine>)
13
Transaction script vs Domain Model
Organizes business logic by procedures where each procedure handles a single request from
the presentation
• Se nella descrizione precedente sostituiamo la parola presentation con la parola servizio si può capire come il pattern Transaction Script fornisca l’interfaccia Coarse Grained richiesta.
• Allora il Domain Model è dannoso per le performances?
14
Service layer - POEAA
15
DDD vs Coarse Grained interfaces
• Le scelte effettuate nella realizzazione del Domain Model non debbono essere influenzate dalle necessità di un modello SOA
• Non è consigliabile snaturare un dominio cercando di realizzare oggetti con interfacce coarse grained.
• Facciamoci aiutare dai pattern per costruire un layer che permetta di rendere il nostro Dominio più adatto ad una comunicazione remota
16
Remote Facade• Questo pattern crea un layer di oggetti con un’interfaccia
coarse grained per accedere da remoto al nostro dominio
• Possiamo strutturare quindi il Remote Facade come un Transaction Script che internamente utilizza gli oggetti di dominio per realizzare operazione complesse
Client
DOMAINClient
Client
17
Data Transfer Objects• Creare un’interfaccia coarse grained su un Domain
Model genera la necessità di trasferire più oggetti o una parte di grafo del dominio in una singola chiamata
• Un DTO è un oggetto che racchiude dentro di se le proprietà di più oggetti del dominio, in questo modo il chiamante trova racchiuso in un singolo oggetto tutte le informazioni di cui ha bisogno.
• Un DTO contiene tutte le informazioni relative ad una funzione del servizio permettendo al chiamante di ignorare l’effettivo grafo degli oggetti implementati dal dominio.
18
DTO
Ordine
cliente
Linea Ordine
1
0..*1..*1
Indirizzo
1Destinazione
Indirizzo
Magazzino
OrdineDTO
Assembler
Creazione
19
Inversione di controllo
• La chiave di volta di un buon servizio è il bassissimo accoppiamento tra i componenti
• I principi di Inversion of Control e di Dependency Injection permettono di ridurre drasticamente l’accoppiamento tra i componenti
• Esistono in rete molte implementazioni open source di questi pattern, in questo modo la loro applicazione è decisamente banale.
20
IoC• AlertManager (Esempio)• Nell’esempio appena visto la classe AlertManager ha due
dipendenze, al logger di log4net ed alla classe MailSender
• Il primo passo è accedere agli oggetti tramite interfaccia
AlertManager IMessageSender MailSender
• L’interfaccia non risolve però il problema della creazione, se il componente AlertManager crea un istanza di MailSender con new la dipendenza rimane
21
Factory e service locators
• Una classe factory rimuove il codice di creazione degli oggetti dall’alert manager
• La classe factory può utilizzare reflection per creare dinamicamente gli oggetti sulla base di settaggi nell’app.config
• L’alert manager chiama un metodo apposito della factory per creare un istanza di un oggetto IMessageSender
• In questo modo l’accoppiamento è diminuito, ma esiste ancora una dipendenza tra AlertManager e classe factory
22
Factory e service locator
AlertManager IMessageSender
MailSenderSmsSender
Creazione
AlertManager IMessageSender
MailSenderSmsSender
Creazione
Factory
23
IoC e DI• Sebbene una classe factory sia in grado di ridurre
fortemente l’accoppiamento non è ancora il risultato ottimale
• I principi di IoC e di DI richiedono che non sia l’oggetto stesso a creare i suoi collaboratori, i quali debbono invece essere forniti dall’esterno
• I due metodi standard tramite i quali un oggetto permette di “iniettare una dipendenza” sono i costruttori e le normali proprietà.
24
Assemblatori e IoC
AlertManager IMessageSender
MailSenderSmsSender
Assembler
Creazione
25
IoC tipo 2 o 3?• Nonostante in letteratura vi sia una distinzione forte tra IoC
tipo 2 o 3 in realtà rivestono due aspetti semantici differenti e vanno utilizzate assieme
• L’IoC di tipo 2 o iniezione per costruttore modella una semantica di dipendenza necessaria
• L’IoC di tipo 3 o setter modella una semantica di dipendenza opzionale
• Nell’esempio la nostra classe AlertManager usa IoC tramite costruttore per IMessageSender, dato che senza sender non può funzionare, per il logger utilizza invece una IoC tramite Setter ad indicare l’opzionalità del parametro.
• Tramite un pattern di Special Case o Null Object abbiamo modellato il logger di default.
26
AOP
• Aspect Oriented Programming è una tecnica di programmazione che cerca di focalizzare l’attenzione sulla separazione degli aspetti di un software
• I tradizionali linguaggi OO permettono di incapsulare tramite il concetto di classe un oggetto con funzionalità ben definite
• Un aspetto è invece una funzionalità che appartiene a più oggetti, esempi classici sono il logging e la security.
27
AOP• Mediante le tecniche di AOP è possibile “iniettare”
codice in una classe esistente. • In .NET e nei principali linguaggi orientati agli oggetti non
è presente un supporto nativo per AOP che deve quindi essere implementata tramite le funzionalità standard del linguaggio
• Da questo deriva che non è possibile utilizzare AOP su qualsiasi classe, a meno che non sia rispettato un prerequisito, il basso accoppiamento.
28
AOP – Interfacce e proxy
• Iniezione tramite interfaccia (decorator pattern)IOrder OrderApp
IOrder OrderApp Aspect
• Iniezione tramite classe base con metodi virtuali
OrderApp OrderProxyApp
Order
29
IoC vs AOP
• Molte delle tecniche proprie di AOP possono essere ottenute tramite un contenitore IoC
Aspect
IOrder OrderApp
Spring/Windsor
IOrder OrderApp
Spring/Windsor
30
Concetti base di AOP• Aspect: la modularizzazione di un concetto la cui
implementazione "tocca" più oggetti• Joinpoint: un punto di un programma dove è
possibile iniettare un aspect• Advice: azione presa dal framework AOP in un
particolare joinpoint• Pointcut: un set di Joinpoint dove deve essere
applicato un advice• Advisor: (Spring.NET) insieme di un advice e di un
pointcut.
31
Framework di AOP
• I framework AoP come Spring.NET basano le loro funzionalità sull’infrastruttura per IoC
• Le tecniche di AOP possono essere adottate in maniera trasparente per le applicazioni fortemente basate su IoC.
• Spring.NET AOP fornisce un framework che permette l’uso delle tecniche di AOP basandosi su contenitori di IoC e in maniera assolutamente trasparente all’applicazione.
32
Esempi