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