a.a. 2004/05Tecnologie Web1 Architetture parte I a.a. 2004-5 parte 1.

a.a. 2004/05 Tecnologie Web 1

Architettureparte I

a.a. 2004-5

parte 1


ARCHITETTURE

Parte I:–L’evoluzione del Client/Server

– Database servers e Fat client

– Architetture Multi-Tier

– CORBA


ARCHITETTURE

Parte II – Business Objects:

• COM (Component Object Model) e DCOM (Distributed COM)

• Enterprise Java Beans (J2EE)

– Microsoft .NET

– SOA (Service Oriented Architecture)

– Web Services

Parte III– UML


Prerequisiti

• Concetti di object oriented design (breve accenno durante il corso)

• MS windows (utente)

• Internet WWW (utente)


Testi Di Riferimento

• Orfali, Harkey, Edwards: “the Essential Distributed objects Survival guide”, WILEY

• Orfali, Harkey: “client/server Programming with Java and CORBA”, WILEY

• Budi Kurniawan: “Java for the Web with Servlets, JSP, and EJB: A Developer's Guide to J2EE Solutions”, Paperback


L’evoluzione del Client/Server

CLIENTSERVERPC

stand alonePC

networking

End User

HOSTsolution

MINIsolution

Enterprise


Allocazione Delle Componenti

DataManagement

Logic/Control

Presentation

SERVER

CLIENT

NETWORK


Allocazione Delle Componenti• Un’applicazione può essere suddivisa logicamente in tre

parti:– la presentazione che gestisce l’interfaccia utente (gestione degli

eventi grafici, controlli formali sui campi in input, help, …)– la logica applicativa vera e propria– la gestione dei dati persistenti su database

• Fisicamente queste componenti dovranno essere allocate su client e server.

• La scelta della politica di allocazione di queste componenti porta alla classificazione della pagina successiva.


Classificazione delle soluzioni Client/Server I

• Timesharing: la soluzione monolitica precedente al client/server, tutto risiede sul server, il terminale è a caratteri, l’interfaccia poco amichevole

• Client Presentation: solo la logica di gestione dell’interfaccia utente è locale al client, è il caso degli X-Terminal ma anche dei browser (senza applet)

• Distributed Application: la logica applicativa è distribuita (ad esempio: controlli sul client, elaborazioni più pesanti sui server. A questa categoria appartengono soluzioni quali: stored procedure, architetture three-tier, browser+applet.


Classificazione delle soluzioni Client/Server II

• Central Database (detto anche “fat client” o “two-tier”): sul server rimangono solo i dati, in rete passano comandi SQL. E’ la soluzione più diffusa nella prima stagione del client/server

• Distributed Database: sui client risiedono anche i dati, la soluzione risolve alcune lentezze del fat client ma con problemi proibitivi di allineamento dati. Ha avuto successo solo in caso di utenti mobili (automazione forza vendita, tecnici di manutenzione impianti…)


Classificazione delle soluzioni Client/Server

Data

Logic

Presentation

Data

Logic

Presentation

Data

Logic

Presentation

Logic

Data

Logic

Presentation

Data

Logic

Presentation

Data

Char. Terminal X-Terminal PC PC PC

TimesharingClient

PresentationDistributedApplication

CentralDatabase

DistributedDatabase

Server

Client

Centralized Decentralized


Le “ere” del Client/Server

Da: Byte Aprile 95


Monoliti (IT stovepipe) - I

• Popolari ai tempi dei mainframe• Monoliti:

– pezzi di codice indivisibili

– controllavano l’intera logica dell’applicazione, dalla gestione (e memorizzazione) dei dati, fino all’interfaccia utente

– gestivano applicazioni stand-alone

• Popolarità dovuta a:– mainframe adatti ad eseguire pochi processi stand-alone,

anzichè diversi processi comunicanti

– non c’erano ancora i database


Monoliti (IT stovepipe) - II

Enterprise

User interface

Logic

Data Management


Architetture client/server - I• Dalla fine degli anni ‘70 alla metà degli anni ‘80

– Diffusione di server più piccoli ed economici dei mainframe, e di workstations e PC

– Diffusione di RDBMS

• Suddivisione delle applicazioni in due parti:– backend (server): gestione di database (+ o – complessi) e

dei compiti di manipolazione dei dati– frontend (client): gestione interfaccia utente maggiore scalabilità, rispetto a monoliti (carico

computazionale distrbuito sui client) sviluppo più veloce di applicazioni che accedono agli

(stessi) dati


Architetture client/server - III

Enterprise

User interface

Logic

Data Management

Client Client Client

Server


Architetture client/server - IISvantaggi:• Traffico di messaggi intenso (frontend comunica

continuamente con server dati)• Logica di business non gestita in componente separata

dell’architettura: suddivisa tra frontend e backend client e server di applicazione dipendono l’uno

dall’altro– difficile riutilizzare interfaccia in servizio che accede a dati

diversi– difficile utilizzare DB da frontend diversi– tendenza a cablare la business logic nell’interfaccia utente

cambio di logica significa cambiare anche interfaccia


Architetture client/server - IV

• Problema: mancato riconoscimento dell’importanza della business logic– Es: servizio accessibile da più device (telefonino, desktop)

stessa logica, interfaccia diversa

Enterprise

User interface

Logic

Data Management

ClientNuovo Client Nuovo Client

Server

AdapterAdapter


PRINCIPALI CARATTERISTICHE:• Standard: SQL, ODBC, DRDA• Stored Procedure• Two Phase Commit• Replicazioni Asincrone On-Line• Data Warehouse

VANTAGGI:• Alta produttività dei linguaggi 4GL• Prodotti maturi ed efficienti• Buona standardizzazione

LIMITI:• Espressività limitata al solo modello entity relationship• Limitata scalabilità e tuning per grandi sistemi

OracleOracleDB2 DB2 MS SQL ServerMS SQL ServerSybase Sybase InformixInformix

Database Servers


Central Database (Fat Client)Esempio di prodotti

RDBMS

Protocollo di rete

Driver DB

Driver ODBC

Applicazione

Protocollo di rete

Scritta in Visual Basic

Driver ODBC Oracle

Oracle SQL*NET

TCP/IP

TCP/IP

Oracle

Esempio di prodotti

Ethernet


Problemi del “Fat Client” I

• Forte sollecitazione della rete - prestazioni penalizzate

• Forte uso delle risorse dei client

• Scalabilità difficile

• Manutenzione costosa

• Accesso ai dati poco protetto da errori di programmazione

• In internet download degli applet lento


Miglioramenti al modello Database Server

• Problemi del “fat client”: uso delle Stored Procedure

• Decentramento: Replicazioni Asincrone On-Line

progettare siti distribuiti su più sedi riducendo i problemi di scalabilità


RDBMS: Stored ProceduresUtilizzando comandiSQL l'interazione client/server èelevata:

• declare C cursor for select * from T where ...

• open C

• fetch C

• update ...

Client Server

declare

open

fetch

update

fetch

update

fetch

update


RDBMS: Stored ProcedureCon le stored procedure l'interazione client/server è ridotta e più efficiente:

• create procedure P @nome varchar(40) declare C cursor ... while (ci sono dati) begin fetch .... if ..... update ... end

• execute P "Rossi"

Client Server

execute

Attenzione: le Stored Procedure non sono portabili da un RDBMS all’altro!Attenzione: le Stored Procedure non sono portabili da un RDBMS all’altro!


Replicazioni Asincrone

Dati primari

Dati primari locali

London

Tokio

New York

DB

DB

DB

Dati replicati


Replicazione Asincrona - caratteristiche

Un prodotto di replicazione dovrebbe garantire:

• Configurabilità dei dati da replicare

• Sincronizzazione automatica dei DB

• Propagazione cambiamenti "al più presto"

• Protezione delle transazioni e integrità referenziale dei dati replicati

• Routing ottimizzato dei dati

• Supporto di più RDBMS

• Supporto di RDBMS localizzati sui PC client (mobile computers)


Replicazione di testata e dettagli di un ordine di acquisto

order 100

item A

item B

DATI PRIMARI

order 100

item A

item B notyet available

DATI REPLICATI

Integrità referenziale


New York

LondonTokio

Singapore SydneyHong Kong Glasgow RomeHamburg

Routing delle repliche


Routing delle repliche

1. informazioni trasferite da New York a Tokio e a Londra,

2. poi da queste ultime ai siti a livello sottostante. 3. New York aggiorna 8 siti tramite due siti (router) minimizza il volume di messaggi trasmessi da New

York.• ogni passaggio ad un livello intermedio implica dei

tempi di giacenza dell'informazione da replicare

mantenere basso il numero di livelli intermedi.


Middleware

• Middleware: software di sistema che permette Middleware: software di sistema che permette l’interazione a livello applicativo fra programmi in un l’interazione a livello applicativo fra programmi in un ambiente distribuitoambiente distribuito

• Facilitano e gestiscono interazioni tra applicazioni su piattaforme eterogenee– LAN ristrette– Complesse applicazioni– Utilizzo di tecnologie Web


Tipologie di Middleware TP monitor (OLTP)

Message Oriented (MOM)

Publish/Subscribe

Object Request Broker (ORB)

Object Transaction Monitor (OTM)


PRINCIPALI CARATTERISTICHE:• Proprietà ACID• Bilanciamento carico dei server• Sincronizzazione in Two Phase Commit• Gestione pool di risorse

VANTAGGI:• Scalabilità e tuning per grandi sistemi• Adatti ad applicazioni mission critical

LIMITI:• Minore produttività (pochi standard)• Uso limitato di linguaggi 4GL

Market ShareMarket Share

1 s t Q t r 2 n d Q t r0

2 0

4 0

6 0

8 0

1 s t Q t r 2 n d Q t r

CICSCICSIMSIMSTuxedoTuxedoEncina/TxSeriesEncina/TxSeriesMS Transaction ServerMS Transaction ServerTIBCO EtxTIBCO Etx

TP Monitors (OLTP: On Line Transaction Processing)


TP Monitors

ServizioServizio

ServizioServizio

ServizioServizio

ServizioServizio

ServizioServizio

Servizio

ServizioServizio

ServizioServizio

ServizioServizio

ServizioServizio

ServizioServizio

Servizio

DATI

Applicazioni “Service Oriented”


TP Monitors• al client sono offerti servizi (procedure remote

dotate di parametri di input e output).• i servizi, dotati di logica applicativa, accedono ai

dati.• Il TPM nasconde ai client la locazione dei servizi

possono essere distribuiti e duplicati su più server permettendo così di applicare tecniche di bilanciamento di carico e di gestione delle cadute di un server).


I servizi di un TP Monitor

• Gestione dei processi server: attivazione, funnelling, monitoraggio e bilanciamento carichi

• Gestione delle Transazioni: proprietà ACID

• Gestione della comunicazione client/server


Proprietà “ACID”

• Una transazione deve essere:–Atomica–Consistente–Isolata–Durevole


DesktopDesktop Work-Work-groupgroup

Depart-Depart-mentment DivisionDivision Enter-Enter-

priseprise

1 user1 user 2 users2 users 100s100s 1000s1000s 10,000s10,000s

InternetInternet

100,000s100,000s

Shared DataShared DataConnectionsConnections

SecuritySecurityContextContext

MultithreadMultithread

MultithreadingMultithreadingLoad BalancingLoad Balancing

MultinodeMultinode

Msg Q’ingMsg Q’ing

MultisiteMultisiteHigh AvailHigh Avail

Fonte: Microsoft

La scalabilità dei sistemi


Architetture Two-Tiers e Three-Tiers



2 0

4 0

6 0

8 0




2 0

4 0

6 0

8 0




2 0

4 0

6 0

8 0




2 0

4 0

6 0

8 0


DB

DB

DB



2 0

4 0

6 0

8 0




2 0

4 0

6 0

8 0




2 0

4 0

6 0

8 0




2 0

4 0

6 0

8 0


DB

DB

DB

minore uso delle risorse

suddivisionepiù razionale dei compiti

livello intermedio


Architetture Multi-TierDatabasDatabasee ServersServers

NC . NC . NetPCNetPC PC PC

ClientClient MobilMobilee

Mail/Mail/GroupwareGroupwareServersServers

MainframMainframeeSystemsSystems

Interfaccia Utente

Logica Applicativa

Dati


Logica Logica ApplicativaApplicativa

Web+ActiveXWeb+ActiveXo applet Javao applet Java

Web+script lato serverWeb+script lato server(ASP, JSP o servlet)(ASP, JSP o servlet)

Visual Basic, C++, Delphi Visual Basic, C++, Delphi Client/ServerClient/Server

Lotus Notes, ExchangeLotus Notes, ExchangeGroupwareGroupware

Applicazioni real-timeApplicazioni real-timebatch, OLTP, M&Qbatch, OLTP, M&Q

PersistenzaPersistenzadei datidei dati

Architetture Three-Tier: molti tipi di interfacce utente, la stessa applicazione


Architetture three-tier - I

• Introdotte all’inizio degli anni ‘90

• Business logic trattata in modo esplicito:– livello 1: gestione dei dati (DBMS, file XML, …..)

– livello 2: business logic (processamento dati, …)

– livello 3: interfaccia utente (presentazione dati, servizi)

• Ogni livello ha obiettivi e vincoli di design propri

• Nessun livello fa assunzioni sulla struttura o implementazione degli altri:– livello 2 non fa assunzioni su rappresentazione dei dati, né

sull’implementazione dell’interfaccia utente

– livello 3 non fa assunzioni su come opera la business logic ..


Architetture three-tier - II

• Non c’è comunicazione diretta tra livello 1 e livello 3– Interfaccia utente non riceve, né inserisce direttamente dati

nel livello di data management

– Tutti i passaggi di informazione nei due sensi vengono filtrati dalla business logic

• I livelli operano senza assumere di essere parte di una specifica applicazione applicazioni viste come collezioni di componenti

cooperanti ogni componente può essere contemporaneamente parte

di applicazioni diverse (e.g., database, o componente logica di configurazione di oggetti complessi)


Architetture three-tier - III

BusinessRules

Enterprise

User interfacePresentation layer

LogicBusiness layer

Data ManagementData layer Data

ServiceData

ServiceData

Service

BusinessRules

BusinessRules

MotifClient

WindowsClient

TelephonyClient

MacClient


Architetture three-tier - IV

User Interface

Application Logic

DBXML

Documents

Dataproviders

Serviceprovider

Serviceconsumer

Directoryservice


Vantaggi di architetture three-tier - I

• Flessibilità e modificabilità di sistemi formati da componenti separate– componenti utilizzabili in sistemi diversi

– modifica di una componente non impatta sul resto del sistema (a meno di cambiamenti negli API)

– ricerca di bug più focalizzata (separazione ed isolamento delle funzionalità del sistema)

– aggiunta di funzionalità all’applicazione implica estensione delle sole componenti coinvolte (o aggiunta di nuove componenti)


Vantaggi di architetture three-tier - II

• Interconnettività– API delle componenti superano il problema degli adattatori

del modello client server N interfacce diverse possono essere connesse allo stesso servizio etc.

– Facilitato l’accesso a dati comuni da parte di applicazioni diverse (uso dello stesso gestore dei dati da parte di business logics diverse)

• Gestione di sistemi distribuiti– Business logic di applicazioni distribuite (e.g., sistemi

informativi con alcuni server replicati e client remoti) aggiornabile senza richiedere aggiornamento dei client

– Aggiornamento dei client comunque costoso


Vantaggi di architetture three-tier - III

• Applicazioni distribuite geograficamente– Data server centrale

– Business logic gestita da server logici regionali

– Client remoti (ev. con business logic per maggior scalabilità)

• Per ridurre traffico di rete e latency del servizio, anche il data server centrale può essere replicato (ma, gestione consistenza dati)


Svantaggi di architetture three-tier - I

• Dimensioni delle applicazioni ed efficienza– Pesante uso della comunicazione in rete latenza del

servizio

– Comunicazione tra componenti richiede uso di librerie SW per scambio di informazioni codice voluminoso

• Legacy software– Molte imprese usano software vecchio (basato su modello

monolitico) per gestire i propri dati

• difficile applicare il modello three-tier per nuove applicazioni

• introduzione di adapters per interfacciare il legacy SW


Three-tier è concettuale, non fisico

Si possono implementare architetture three-tier su due livelli di macchine, o anche su uno solo...

Data and Logic Server Clients

User Interface

User Interface

DataComponents

LogicRules


Architetture n-Tier - I

Permettono configurazioni diverse. Elementi fondamentali:

• Interfaccia utente (UI)– gestisce interazione con utente

– può essere un web browser, WAP minibrowser, interfaccia grafica, …

• Presentation logic– definisce cosa UI presenta e come gestire le richieste utente

• Business logic– gestisce regole di business dell’applicazione


Architetture n-Tier - II

• Infrastructure services– forniscono funzionalità supplementari alle componenti

dell’applicazione (messaging, supporto alle transazioni, …)

• Data layer: – livello dei dati dell’applicazione


Architetture n-Tier - III

Browser

DBXML

Documents

Presentation Logic

Business LogicServices

Application client

Firewall


Applicazione Web-based tipica - I

• Interfaccia utente: gestita sul browser utente• Logica applicativa: gestita sul server, che si

interfaccia al web attraverso Web Server• Livello dei dati: su database, eventualmente

localizzato su macchina diversa da quella del Web Server, per questioni di sicurezza

WebServer Business logic

Browserutente

HTTP


Applicazione Web-based tipica - II

• Richiesta di pagina HTML statica (pagina HTML memorizzata nel file system dell’applicazione – il codice della pagina non viene generato eseguendo programmi applicativi sul server)

WebServer

Local File System

/htdocs/hello.html

Request: http://patzer/hello.html

Response: HTML code

Browserutente


Applicazione Web-based tipica - III

• Richiesta di pagina dinamica (pagina HTML generata dinamicamente, sulla base della richiesta del client – codice della pagina generato eseguendo programmi applicativi sul server)

WebServer Business logic

Request: http://www.di.unito.it/service1.html

Response: pagina HTML di risposta, con eventuali linke bottoni per continuare interazione

Browserutente


Browser Web• Può essere visto come interfaccia utente universale

– Invoca Web Server per richiedere pagine statiche o dinamiche

– Riceve contenuti web da Web Server invocato e li presenta sulla macchina dell’utente• Browser moderni (MS Explorer, Netscape Navigator, …)

interpretano codice HTML• Alcuni browser interpretano codice XML

– Può eseguire script (e.g., javascript) localmente, per effettuare semplici computazioni (e.g., controllo correttezza input utente)

– Può scaricare plug-in da Web Server per eseguire programmi localmente (e.g., animazioni Flash o altro)


Web Server

Programma– gira su una macchina server accessibile da internet – resta in ascolto di richieste (da parte di client web)

su porta HTTP. E.g., http://www.di.unito.it:8080– gestisce le richieste che arrivano (recupera pagina

html richiesta, esegue programmi, invoca programmi associati a servizi richiesti, etc.)

– restituisce a client una risposta (risultato della richiesta, messaggio di errore)


Publish & SubscribePublish “BORSA.MILANO.*”

Information Bus

Subscribe “BORSA.MILANO.COMIT”

Subscribe “BORSA.*”

“BORSA.MILANO.SANPAOLO=31.123”“BORSA.MILANO.COMIT=7.739”

“BORSA.MILANO.SANPAOLO=31.123”“BORSA.MILANO.COMIT=7.739”“BORSA.NEWYORK.COCACOLA=$135

“BORSA.MILANO.COMIT=7.739”


Modelli di comunicazione fra programmi

Conversational

Request/Reply (RPC)

ProgramA

ProgramB

Call

ReturnProgram

AProgram

B

Message PassingReceiveSend

Message Queuing

Queue

Enqueue Dequeue

Publish and Subscribe

Program C

Publish Subscribe

ProgramA

ProgramB

ProgramA

ProgramB

ProgramA

ProgramB

Indipendenza dalla locazione fisica del destinatarioIndipendenza dalla locazione fisica del destinatario

Indipendenza dalla locazione fisica e dalla Indipendenza dalla locazione fisica e dalla disponibilità immediata del destinatariodisponibilità immediata del destinatario

Indipendenza dalla locazione fisica, dalla Indipendenza dalla locazione fisica, dalla disponibilità immediata, dall’identità e dal disponibilità immediata, dall’identità e dal numero di destinatarinumero di destinatari


Service-oriented Architecture Interaction• Uses interface metadata

• One-to-one connections

• Client directs flow

• Linear path of execution

• Closed to unforeseen input once a flow is started

Interfacestub

Interface proxy

Client Server

Service-oriented or Event-driven

Source Sink

Event-driven Notification• Uses event descriptor metadata

• Many-to-many connections

• Sink (recipient) determines flow

• Dynamic, parallel, asynchronous flows

• Can react to new external input while process is in flight

Event


Applicazioni del Middleware

Applicazioni interattive, sincrone “request-reply”:

TP Monitor (OLTP)


Object Transaction Monitor (OTM) e Application Server (AS)

Comunicazioni unidirezionali, asincrone “store & forward”:

Message Oriented (MOM)

Publish/Subscribe

SVILUPPO NUOVE APPLICAZIONI

INTEGRAZIONE APPLICAZIONI o e-BUSINESS


Approccio ad Oggetti


Approccio ad Oggetti (1)

• Incapsulamento di dati e regole (attributi e metodi di una Classe)

• Ereditarietà

• PolimorfismoForma

CoordinateCentro

Disegna( )LeggiCoordinate( )ModificaCoordinate( )

Cerchio

Raggio

Rettangolo

AltezzaLarghezza

SpazioGrafico

Scala : intero

ModificaScala ()LeggiScala ()

Arco

DaA

Window

DimensioniFormeContenute

ScrollDown( )ScrollUp( )

Oggetto Grafico

Disegna( )

Lista Forme Contenute

Primo( )Prossimo( )

contiene

è contenuto


Approccio ad Oggetti (2)

• Librerie di classi e Frameworks (infrastrutture di classi)

• Legami (binding) statici e dinamici• Relazioni tra gli oggetti:

– specializzazione– associazione– aggregazione


Relazioni fra gli oggetti

Generalizzazione /Generalizzazione /SpecializzazioneSpecializzazione

AssociazioneAssociazione

AggregazioneAggregazione

Mammiferi

Cani File

Directory

Azienda

Impiegato

lavora presso


Approccio ad Oggetti - motivazioni

• Rende automatici alcuni principi di buona programmazione (modularità, incapsulamento)

• Favorisce il Riuso del Software

• Semplifica la manutenzione del software

• Possiede una buona base metodologica (OMT, Use Case, UML, …)

• Favorisce lo sviluppo a componenti


Limiti storici della Programmazione ad Oggetti

• SmallTalk, C++, … non interoperabili

• Gli oggetti sono locali al processo che li ha generati

• Quindi sono oggetti non persistenti

• OODBMS privi di standard e spesso legati ai linguaggi di programmazione



Object Request BrokerObject Request Broker



2 0

4 0

6 0

8 0



DistributedDistributedOperatingOperating

EnvironmentEnvironment

Integrated StorageIntegrated Storage

Business ProcessBusiness Process

User Interface & NavigationUser Interface & NavigationToolsTools

Microsoft COM/DCOM

OMG CORBA

Object Request Brokers


CORBA (Common Object Request Broker Architecture)

• Uno standard per architetture distribuite ad oggetti definito dall’Object Management Group (OMG) http://www.omg.org/


Object management architecture


Java di SunSoft

• Interpretato (bytecode)

• È direttamente portabile su molte piattaforme

• Sicuro

• Adatto ad applicazioni Internet/Intranet

• Annulla i costi della software distribution

• Indirizzato ad hardware di basso costo


Dall’HTML statico alle applicazioni Client/Server1


CORBA e Internet


HTML Dinamico

InterneInternet t

(htpp)(htpp)

WebWebServerServer

HTMLHTML

JSPJSP servletservlet BusinessBusinessObjectsObjects DATIDATI

servletservlet

browserbrowser1. richiesta .jsp1. richiesta .jsp

4. ritorna html4. ritorna html

2. richiesta dati2. richiesta dati

3. generazione html3. generazione html

Tier 1Tier 1 Tier 2Tier 2 Tier 3Tier 3

Application server

Date post:	03-May-2015
Category:	Documents
Upload:	teodoro-vitali
View:	218 times
Download:	2 times