Evoluzione delle Architetture Distribuite

Transcript

1 Evoluzione delle Architetture Distribuite 1 Evoluzione dell architettura Dall architettura centralizzata all architettura distribuita Applicazioni centralizzate Applicazioni Client/Server Applicazioni Multi-Tier Terminali Mainframe Client Server Client-Tier Middle-Tier Resource-Tier Dati Dati Dati Dati

2 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 3 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 Terminali 1980 Dati Mainframe Terminali 4

3 Motivi dell evoluzione Tecnologia abilitante Nascita della rete Nascita del Client-Rich Driver di business L informatizzazione raggiunge le piccolemedie imprese 5 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 6

4 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 Fat-Client Logica di business Server Dati 7 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 8

5 Il Modello a Layer Separazione delle funzionalità logiche del software in livelli Definizione chiara delle interfacce e dei protocolli di comunicazione tra i livelli Possibilità di ogni livello di chiedere e fornire servizi a livelli diversi Possibilità di apportare modifiche ai vari livelli limitando al minimo l impatto di tali modifiche su altri livelli 9 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 10

6 Tre Livelli Pro: Scalabile Sicurezza a livello di servizio Incapsulamento della business logic Contro: Difficoltà nel design, sviluppo e amministrazione Client-Tier Business-Tier Resource-Tier Dati 11 Verso il modello distribuito La necessità di specializzare i server per servizi diversi La necessità di maggiore scalabilità La necessità di un alta affidabilità e bilanciamento del carico La necessità di integrare servizi che risiedono su server differenti 12

7 Verso il modello distribuito: rischi di un evoluzione non controllata Client-Tier Web-Tier Business-Tier Resource-Tier Dati Dati 13 Il Middleware I Middleware: letteralmente lo strato posto nel mezzo, vanno a coprire le necessità di integrazione e comunicazione delle applicazioni distribuite Comunemente i Middleware sono suddivisibili in tre macroaree: 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 14

8 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 15 Application Server Gli architetti di applicazioni distribuite notano che nel disegno del livello intermedio si devono affrontare una serie di problemi indipendenti dal business domain 16

9 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 17 Ambienti di esecuzione controllata 18

10 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 19 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 20

11 Interception Queste problematiche vengono gestite dall application server (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 21 Interception Container Client Smart Skeleton Server 22

12 Lifecycle Creazione e distruzione degli oggetti server Gestione automatica dei momenti di sincronizzazione col database 23 Lifecycle 24

13 Controllo della concorrenza Serializzazione degli accessi agli oggetti: Per oggetto Per metodo Gestione di pool di oggetti equivalenti 25 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 26

14 Controllo delle transazioni Delimitazioni delle transazioni a carico del container Il container gestisce le risorse di carattere transazionale Database Sistemi di messaging Sistemi legacy 27 Controllo delle transazioni Server Container Risorsa getrisorsa() begintransaction() Operazione1() Operazione2() releaserisorsa() committransaction() 28

15 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. 29 Container IIOP Listener RMI Listener Controllo Concorrenza Autenticazione Centralizzata Server Persistenza Database SOAP Listener 30

16 Tipi di servizi Sincroni direttamente invocati da un client Asincroni innescati da eventi quali: Messaggi Timer 31 Confronto sistemi di elaborazione distribuita 32

17 Sistemi di elaborazione distribuita Esistono molti altri sistemi di elaborazione distribuita oltre a CORBA RMI DCOM SOAP Quale scegliere in un progetto? 33 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) 34

18 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 serializzazione degli oggetti java 35 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 36

19 SOAP E uno standard (W3C) E multilinguaggio E multipiattaforma Può usare molti protocolli, in particolare è importante HTTP Come formato dati usa XML 37 Schema riassuntivo CORBA RMI DCOM SOAP Standard Sì No No Sì Multilinguaggio Sì No Sì Sì Multipiattaforma Sì Sì No Sì Protocollo IIOP RMI Wire protocol Proprietario HTTP e altri Formato dati Proprietario Proprietario Proprietario XML 38

20 Importanza dell architettura: un esempio reale 39 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. 40

21 Architettura (attuale) Canali di accesso Servizi aziendali Internet CORBA CRM Call Center CORBA Motore di integrazione Emulazione 3270 Servizi bancari CICS Agenzie JDBC Servizi Assicurativi Database 41 Architettura (attuale) Problemi: Impossibilità di effettuare transazioni che coinvolgano più di una sorgente dati. Disomogeneità dei protocolli di comunicazione Disomogeneità dei formati di comunicazione 42

22 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. 43 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 44

23 Architettura (a tendere) Canali di input Servizi aziendali Internet CRM JMS (XML) Call Center CORBA Motore di integrazione Coda di messaggi Servizi bancari Agenzie JDBC Servizi Assicurativi Two phase commit Database 45 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 criteri architetturali porta ad un sistema complesso e difficilmente controllabile. 46

24 Aspetti principali dell architettura enterprise Architettura tecnologica Hardware Sistemi operativi Linguaggi DBMS Middleware Pattern di disegno architetturale Due livelli/multilivello Fat client/thin client Architettura centralizzata o distribuita Gestione delle informazioni Modello degli oggetti Modello dei dati Modello dei processi Database condivisi Riuso dei componenti software Modello degli eventi Standard tecnologici definiti internamente all azienda. Concetti riusabili spesso raccolti in common practices. Modelli fortemente dipendenti dal business d azienda. Riferimenti disponibili in best practices 47 Problemi e difficoltà dell evoluzione Problemi di uniformità: Dell architettura tecnologica Dell architettura applicativa Dell informazione 48

25 Problemi di uniformità tecnologica ed applicativa Applicazioni legacy Applicazioni acquistate Progresso tecnologico Sistemi sviluppati ad hoc Applicazione Custom Pacchetto commerciale Applicazioni Legacy 49 Problemi di uniformità dell informazione Esposizione dell oggetto cliente Modello degli oggetti Modello dei dati Modello dei processi Database condivisi Riuso dei componenti software Modello degli eventi Cliente Applicazione Legacy Cliente Applicazione Nuova 50

26 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à 51 Evoluzione delle architetture Le esigenze di business rendono sempre più importante l integrazione tra componenti e sistemi Applicazioni verticali debolmente accoppiate (batch), spesso tecnologicamente disomogenee 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 Insieme di sistemi informativi, o evoluzione di un S.I., dove tipicamente i dati sono scambiati in maniera asincrona

27 Modello ideale Marketplace Applicazione a 2 livelli Suite di applicazioni Confine del sistema informativo Bus di comunicazione Enterprise Applicazione legacy Applicazione acquistata Applicazione ad hoc Società prodotto 53 54