1

Evoluzione delle Architetture Distribuite

2

Dall’architettura centralizzata all’architettura distribuita

Evoluzione dell’architettura

Applicazioni centralizzate Applicazioni Client/Server

Dati

MainframeTerminali

Resource-TierClient-Tier

Dati

Middle-Tier

Applicazioni Multi-Tier

ServerClient

Dati

Dati

1980 1990

3

Il Modello Centralizzato

• L’applicazione gira su una unica macchina (necessariamente potente)

• L’applicazione deve gestire i dati, la logica di business e l’interfaccia utente

4

Modello centralizzato (continua …)

Pro:• Sicurezza a livello di funzioni• Efficiente

(non si ha l’overhead di comunicazione remota)

• Sviluppo relativamente semplice

Contro:• Hardware costoso• Chiuso (problemi di

integrazione)• Scalabilità solo verticale

Dati

Mainframe

Terminali Terminali

1980

5

Motivi dell’evoluzione

Tecnologia abilitante• Nascita della rete• Nascita del Client-Rich

Driver di business• L’informatizzazione raggiunge le piccole-

medie imprese

6

Il Modello Client Server

• Il Client richiede dei servizi al server• Il Server esegue le richieste ed eventualmente

restituisce il risultato• Parte consistente della logica di business gira sul

Client• Client e server comunicano mediante un protocollo

ben definito • Client e server possono essere sviluppati da enti

differenti • Più client possono interrogare lo stesso server

7

Modello Client/Server

Pro:• Hardware e sviluppo

poco costoso • Aperto

Contro:• Alti costi di amministrazione

(Total Cost of Ownership)• Sicurezza a livello di dati• Poco scalabile

ServerFat-Client

Dati

Logica di business

8

Motivi dell’evoluzione

Tecnologia abilitante• Standardizzazione dei protocolli di rete• Ampliamento della banda

Driver di business• Necessità di distribuzione dell’informazione e dei

servizi su nuovi canali• Necessità di gestire on-line volumi molto maggiori

di transazioni• Necessità di evitare il single point of failure

9

Il Modello a Layer

Separazione delle funzionalità logiche del software in livelliDefinizione chiara delle interfacce e dei protocolli di comunicazione tra i livelliPossibilità di ogni livello di chiedere e fornire servizi a livelli diversiPossibilità di apportare modifiche ai vari livelli limitando al minimo l’impatto di tali modifiche su altri livelli

10

Tre Livelli

• Client-tier: livello dell’interfaccia utente, generalmente un client “leggero”

• Business-tier: livello dove risiedono i componenti che implementano la logica di business

• Resource-tier: livello dei sistemi informativi di back-end che si occupano della gestione dei dati e nel caso delle banche della gran parte delle funzioni core

11

Tre Livelli

Pro:• Scalabile• Sicurezza a livello di servizio• Incapsulamento della

business logic

Contro:• Difficoltà nel design,

sviluppo e amministrazione

Resource-TierClient-Tier

Dati

Business-Tier

12

Verso il modello distribuito

La necessità di specializzare i server per servizi diversiLa necessità di maggiore scalabilitàLa necessità di un’alta affidabilità e bilanciamento del caricoLa necessità di integrare servizi che risiedono su server differenti

13

Verso il modello distribuito: rischi di un’evoluzione non controllata

Resource-TierClient-Tier

Dati

Web-Tier

Dati

Business-Tier

14

Il Middleware

I Middleware: letteralmente lo strato posto nel mezzo, vanno a coprire le necessità di integrazione e comunicazione delle applicazioni distribuiteComunemente i Middleware sono suddivisibili in tre macro-aree:– Basic Middleware ad esempio: Remote Procedure Call Based

Middleware (RPC), Message Oriented Middleware (MOM), Distributed Object Computing Middleware (DOC)

– Platform Middleware ad esempio: gli Application Servers, i TPMonitor, gli ORB e i Web Integration Servers

– Integration Middleware ad esempio: gli Integration Broker e i Business Process Managers

15

Vantaggi dei Middleware a oggetti distribuiti

• Permette di razionalizzare le comunicazioni• Porta ad un’uniformità tecnologica e applicativa• Espone un’interfaccia chiara per l’accesso ai servizi

16

Gli architetti di applicazioni distribuite notano che nel disegno del livello intermedio si devono affrontare una serie di problemi indipendenti dal business domain

Application Server

17

Problemi comuni

• Lifecycle degli oggetti server (persistenza dei dati)• Controllo della concorrenza degli accessi• Autenticazione centralizzata• Controllo delle transazioni• Trasparenza rispetto allo strato di comunicazione

18

Ambienti di esecuzione controllata

19

Ambienti di esecuzione controllata

• Tipicamente si trovano in architetture a tre livelli• Il livello 2 (business logic) deve affrontare una serie

di problemi indipendenti dall’ambito dell’applicazione e generalmente trasversali rispetto a tutti i tipi di applicazioni

20

Problemi comuni

• Lifecycle degli oggetti server (persistenza dei dati)• Controllo della concorrenza degli accessi• Controlli di sicurezza• Controllo delle transazioni• Trasparenza rispetto allo strato di comunicazione

Alcuni di questi ricalcano da vicino i temi affrontati dai CORBA Services

21

Interception

Queste problematiche vengono gestite dall’applicationserver (container) con la tecnica dell’interception:– Il componente server non è direttamente in ascolto delle

richieste di servizio. – Gli viene anteposto un server controllato dal container

che esegue delle preelaborazioni

22

Interception

Container

Server

Smart Skeleton

Client

23

Lifecycle

• Creazione e distruzione degli oggetti server• Gestione automatica dei momenti di sincronizzazione

col database

24

Lifecycle

25

Controllo della concorrenza

• Serializzazione degli accessi agli oggetti:– Per oggetto– Per metodo

• Gestione di pool di oggetti equivalenti

26

Controlli di sicurezza

La gestione dei controlli di sicurezza non dovrebbe essere a carico dell’applicazione. – Integrabile con sistemi di directory esterni – Definita sulla base di una configurazione passata

all’application server, la definizione può essere per• Dominio applicativo • Oggetto• Singolo metodo• Metodo

Ci sono due temi da affrontare:– Autenticazione– Autorizzazione

27

Controllo delle transazioni

• Delimitazioni delle transazioni a carico del container• Il container gestisce le risorse di carattere

transazionale– Database– Sistemi di messaging– Sistemi legacy

28

Controllo delle transazioni

Server Container Risorsa

getRisorsa()

beginTransaction()

Operazione1()

Operazione2()

releaseRisorsa()commitTransaction()

29

Trasparenza rispetto allo strato di comunicazione

• Il container può essere in grado di ricevere richieste di servizio su più di un protocollo e quindi “tradurre” queste richieste in chiamate al server

• Questa è una caratteristica avanzata:– Primi tentativi di avere server CORBA e di WebServices.

30

Container

IIOPListener

RMIListener

SOAPListener

ControlloConcorrenza

AutenticazioneCentralizzata DatabaseServer Persistenza

31

Tipi di servizi

• Sincroni – direttamente invocati da un client• Asincroni – innescati da eventi quali:

– Messaggi– Timer

32

Confronto sistemi di elaborazione distribuita

33

Sistemi di elaborazione distribuita

• Esistono molti altri sistemi di elaborazione distribuita oltre a CORBA– RMI– DCOM– SOAP

• Quale scegliere in un progetto?

34

CORBA

• E’ uno standard (OMG)• E’ multilinguaggio• E’ multipiattaforma• Usa come protocollo di trasporto IIOP su reti IP• Usa come formato dati un formato proprietario

(definito con IDL)

35

RMI

• E’ il sistema di elaborazione distribuita del mondo java

• E’ monolinguaggio• E’ multipiattaforma• Come protocollo di trasporto usa RMI Wire protocol di

default ma può usare IIOP o HTTP (con alcune limitazioni)

• Come formato dati usa il formato di serializzazionedegli oggetti java

36

DCOM (.Net Remote)

• E’ il sistema di elaborazione distribuita del mondo microsoft

• E’ multilinguaggio (il linguaggio deve essere supportato da microsoft)

• E’ monopiattaforma • Come protocollo usa un protocollo proprietario • Come formato dati usa un formato proprietario

37

SOAP

• E’ uno standard (W3C)• E’ multilinguaggio• E’ multipiattaforma• Può usare molti protocolli, in particolare è importante

HTTP• Come formato dati usa XML

38

Schema riassuntivo

XMLProprietarioProprietarioProprietarioFormato dati

HTTP e altri ProprietarioRMI WireprotocolIIOPProtocollo

SìNoSìSìMultipiattaforma

SìSìNoSìMultilinguaggio

SìNoNoSìStandard

SOAPDCOMRMICORBA

39

Importanza dell’architettura: un esempio reale

40

Un esempio Reale

Istituto assicurativo che diventa banca e vuole offrire tutti i propri servizi via web– I servizi assicurativi sono gestiti dal CED interno– I servizi bancari sono appaltati ad un ASP esterno– Si introduce un’applicazione di CRM con l’obiettivo di

avere un’anagrafica unica del cliente.

41

Architettura (attuale)

Internet

Call Center

Agenzie

Canali di accesso

Motore di integrazione

CRM

Servizi bancari

Servizi Assicurativi

CO

RB

A

Servizi aziendali

CORBA

CICS

Emulazione 3270

JDBC

Database

42

Architettura (attuale)

Problemi:– Impossibilità di effettuare transazioni che coinvolgano

più di una sorgente dati.– Disomogeneità dei protocolli di comunicazione– Disomogeneità dei formati di comunicazione

43

Operazioni su più sorgenti dati

Necessaria per qualunque operazione perché l’applicazione utilizza sempre un’applicazione aziendale e il proprio database.

Soluzione:– Introduzione del protocollo two phase commit.

44

Disomogeneità dei dati e dei protocolli

Non è un problema insormontabile, ma complica la vita al programmatore che deve rifare le stesse cose per ogni formato dati e per ogni protocollo (avere diversi protocolli introduce sempre dei problemi di carattere tecnologico)

Soluzione:– Introduzione di un’unica interfaccia verso le applicazioni

aziendali.– Definizione di un unico formato dati per descrivere le

transazioni

45

Architettura (a tendere)

Internet

Call Center

Agenzie

Canali di input

Motore di integrazione

CRM

Servizi bancari

Servizi Assicurativi

Database

CO

RB

A

Servizi aziendali

JDBC

Coda di messaggi

Two phase commit

JMS (XML)

46

Necessità di un’architettura controllata

• A fronte delle richieste del business il sistema informativo è costretto a crescere, modificarsi e adeguarsi.

• Uno sviluppo non coordinato secondo criteriarchitetturali porta ad un sistema complesso e difficilmente controllabile.

47

Aspetti principali dell’architettura enterprise

“Pattern di disegno architetturale”

• Hardware• Sistemi operativi• Linguaggi• DBMS• Middleware• …

• Modello degli oggetti• Modello dei dati• Modello dei processi• Database condivisi• Riuso dei componenti software• Modello degli eventi• …

• Due livelli/multilivello• Fat client/thin client• Architettura

centralizzata o distribuita

• …

Gestione delle informazioniArchitettura tecnologica

Concetti riusabili spesso raccolti in common

practices.

Modelli fortemente dipendenti dal business d’azienda. Riferimenti

disponibili in best practices

Standard tecnologici definiti internamente

all’azienda.

48

Problemi e difficoltà dell’evoluzione

Problemi di uniformità: • Dell’architettura tecnologica• Dell’architettura applicativa• Dell’informazione

49

Problemi di uniformità tecnologica ed applicativa

• Applicazioni legacy• Applicazioni acquistate• Progresso tecnologico• Sistemi sviluppati ad hoc

Applicazione Custom Pacchetto commerciale Applicazioni Legacy

50

Problemi di uniformità dell’informazione

Modello degli oggettiModello dei datiModello dei processiDatabase condivisiRiuso dei componenti softwareModello degli eventi

Applicazione Nuova

Cliente

Applicazione Legacy

Cliente

Esposizione dell’oggettocliente

51

Benefici di un’architettura

• Standardizzazione– Efficienza– Sfruttamento della tecnologia– Controllo dei costi

• Workflow– Processi di business modellati nel sistema– Interoperabilità delle funzioni di business– Integrazione delle applicazioni

• Vision– Agilità nel cambiamento– Capacità di cogliere le opportunità di business– Competitività

52

Evoluzione delle architetture

Applicazioni verticali debolmente accoppiate

(batch), spesso tecnologicamente

disomogenee

Insieme di sistemi informativi, o evoluzione di un S.I., dove tipicamente i

dati sono scambiati in maniera asincrona

Insieme di applicazioni distribuite che devono

potere comunicare fra loro point-to-point

Insieme di applicazioni distribuite che devono

potere comunicare fra loro in maniera sincrona usando di un bus

1970 1980 1990 2000

Le esigenze di business rendono sempre più importante l’integrazione tra componenti e sistemi

53

Modello ideale

Bus di comunicazione Enterprise

Suite di applicazioni Applicazione a 2 livelli

Applicazione legacy Applicazione acquistata Applicazione ad hoc

Società prodotto

MarketplaceConfine del sistem

a informativo

54