Post on 03-May-2015
a.a. 2004/05 Tecnologie Web 1
Architettureparte I
a.a. 2004-5
parte 1
a.a. 2004/05 Tecnologie Web 2
ARCHITETTURE
Parte I:–L’evoluzione del Client/Server
– Database servers e Fat client
– Architetture Multi-Tier
– CORBA
a.a. 2004/05 Tecnologie Web 3
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
a.a. 2004/05 Tecnologie Web 4
Prerequisiti
• Concetti di object oriented design (breve accenno durante il corso)
• MS windows (utente)
• Internet WWW (utente)
a.a. 2004/05 Tecnologie Web 5
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
a.a. 2004/05 Tecnologie Web 6
L’evoluzione del Client/Server
CLIENTSERVERPC
stand alonePC
networking
End User
HOSTsolution
MINIsolution
Enterprise
a.a. 2004/05 Tecnologie Web 7
Allocazione Delle Componenti
DataManagement
Logic/Control
Presentation
SERVER
CLIENT
NETWORK
a.a. 2004/05 Tecnologie Web 8
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.
a.a. 2004/05 Tecnologie Web 9
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.
a.a. 2004/05 Tecnologie Web 10
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…)
a.a. 2004/05 Tecnologie Web 11
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
a.a. 2004/05 Tecnologie Web 12
Le “ere” del Client/Server
Da: Byte Aprile 95
a.a. 2004/05 Tecnologie Web 13
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
a.a. 2004/05 Tecnologie Web 14
Monoliti (IT stovepipe) - II
Enterprise
User interface
Logic
Data Management
a.a. 2004/05 Tecnologie Web 15
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
a.a. 2004/05 Tecnologie Web 16
Architetture client/server - III
Enterprise
User interface
Logic
Data Management
Client Client Client
Server
a.a. 2004/05 Tecnologie Web 17
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
a.a. 2004/05 Tecnologie Web 18
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
a.a. 2004/05 Tecnologie Web 19
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
a.a. 2004/05 Tecnologie Web 20
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
a.a. 2004/05 Tecnologie Web 21
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
a.a. 2004/05 Tecnologie Web 22
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à
a.a. 2004/05 Tecnologie Web 23
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
a.a. 2004/05 Tecnologie Web 24
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!
a.a. 2004/05 Tecnologie Web 25
Replicazioni Asincrone
Dati primari
Dati primari locali
London
Tokio
New York
DB
DB
DB
Dati replicati
a.a. 2004/05 Tecnologie Web 26
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)
a.a. 2004/05 Tecnologie Web 27
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
a.a. 2004/05 Tecnologie Web 28
New York
LondonTokio
Singapore SydneyHong Kong Glasgow RomeHamburg
Routing delle repliche
a.a. 2004/05 Tecnologie Web 29
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.
a.a. 2004/05 Tecnologie Web 30
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
a.a. 2004/05 Tecnologie Web 31
Tipologie di Middleware TP monitor (OLTP)
Message Oriented (MOM)
Publish/Subscribe
Object Request Broker (ORB)
Object Transaction Monitor (OTM)
a.a. 2004/05 Tecnologie Web 32
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)
a.a. 2004/05 Tecnologie Web 33
TP Monitors
ServizioServizio
ServizioServizio
ServizioServizio
ServizioServizio
ServizioServizio
Servizio
ServizioServizio
ServizioServizio
ServizioServizio
ServizioServizio
ServizioServizio
Servizio
DATI
Applicazioni “Service Oriented”
a.a. 2004/05 Tecnologie Web 34
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).
a.a. 2004/05 Tecnologie Web 36
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
a.a. 2004/05 Tecnologie Web 37
Proprietà “ACID”
• Una transazione deve essere:–Atomica–Consistente–Isolata–Durevole
a.a. 2004/05 Tecnologie Web 38
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
a.a. 2004/05 Tecnologie Web 39
Architetture Two-Tiers e Three-Tiers
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
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
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
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
DB
DB
DB
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
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
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
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
DB
DB
DB
minore uso delle risorse
suddivisionepiù razionale dei compiti
livello intermedio
a.a. 2004/05 Tecnologie Web 40
Architetture Multi-TierDatabasDatabasee ServersServers
NC . NC . NetPCNetPC PC PC
ClientClient MobilMobilee
Mail/Mail/GroupwareGroupwareServersServers
MainframMainframeeSystemsSystems
Interfaccia Utente
Logica Applicativa
Dati
a.a. 2004/05 Tecnologie Web 41
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
a.a. 2004/05 Tecnologie Web 42
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 ..
a.a. 2004/05 Tecnologie Web 43
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)
a.a. 2004/05 Tecnologie Web 44
Architetture three-tier - III
BusinessRules
Enterprise
User interfacePresentation layer
LogicBusiness layer
Data ManagementData layer Data
ServiceData
ServiceData
Service
BusinessRules
BusinessRules
MotifClient
WindowsClient
TelephonyClient
MacClient
a.a. 2004/05 Tecnologie Web 45
Architetture three-tier - IV
User Interface
Application Logic
DBXML
Documents
Dataproviders
Serviceprovider
Serviceconsumer
Directoryservice
a.a. 2004/05 Tecnologie Web 46
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)
a.a. 2004/05 Tecnologie Web 47
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
a.a. 2004/05 Tecnologie Web 48
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)
a.a. 2004/05 Tecnologie Web 49
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
a.a. 2004/05 Tecnologie Web 50
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
a.a. 2004/05 Tecnologie Web 51
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
a.a. 2004/05 Tecnologie Web 52
Architetture n-Tier - II
• Infrastructure services– forniscono funzionalità supplementari alle componenti
dell’applicazione (messaging, supporto alle transazioni, …)
• Data layer: – livello dei dati dell’applicazione
a.a. 2004/05 Tecnologie Web 53
Architetture n-Tier - III
Browser
DBXML
Documents
Presentation Logic
Business LogicServices
Application client
Firewall
a.a. 2004/05 Tecnologie Web 54
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
a.a. 2004/05 Tecnologie Web 55
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
a.a. 2004/05 Tecnologie Web 56
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
a.a. 2004/05 Tecnologie Web 57
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)
a.a. 2004/05 Tecnologie Web 58
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)
a.a. 2004/05 Tecnologie Web 59
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”
a.a. 2004/05 Tecnologie Web 60
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
a.a. 2004/05 Tecnologie Web 61
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
a.a. 2004/05 Tecnologie Web 62
Applicazioni del Middleware
Applicazioni interattive, sincrone “request-reply”:
TP Monitor (OLTP)
Object Request Broker (ORB)
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
a.a. 2004/05 Tecnologie Web 63
Approccio ad Oggetti
a.a. 2004/05 Tecnologie Web 64
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
a.a. 2004/05 Tecnologie Web 65
Approccio ad Oggetti (2)
• Librerie di classi e Frameworks (infrastrutture di classi)
• Legami (binding) statici e dinamici• Relazioni tra gli oggetti:
– specializzazione– associazione– aggregazione
a.a. 2004/05 Tecnologie Web 66
Relazioni fra gli oggetti
Generalizzazione /Generalizzazione /SpecializzazioneSpecializzazione
AssociazioneAssociazione
AggregazioneAggregazione
Mammiferi
Cani File
Directory
Azienda
Impiegato
lavora presso
a.a. 2004/05 Tecnologie Web 67
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
a.a. 2004/05 Tecnologie Web 68
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
a.a. 2004/05 Tecnologie Web 69
Object Request Broker (ORB)
Object Request BrokerObject Request Broker
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
a.a. 2004/05 Tecnologie Web 70
DistributedDistributedOperatingOperating
EnvironmentEnvironment
Integrated StorageIntegrated Storage
Business ProcessBusiness Process
User Interface & NavigationUser Interface & NavigationToolsTools
Microsoft COM/DCOM
OMG CORBA
Object Request Brokers
a.a. 2004/05 Tecnologie Web 71
CORBA (Common Object Request Broker Architecture)
• Uno standard per architetture distribuite ad oggetti definito dall’Object Management Group (OMG) http://www.omg.org/
a.a. 2004/05 Tecnologie Web 72
Object management architecture
a.a. 2004/05 Tecnologie Web 73
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
a.a. 2004/05 Tecnologie Web 74
Dall’HTML statico alle applicazioni Client/Server1
a.a. 2004/05 Tecnologie Web 75
CORBA e Internet
a.a. 2004/05 Tecnologie Web 76
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