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

Presentazione sul tema: "a.a. 2004/05Tecnologie Web1 Architetture parte I a.a. 2004-5 parte 1."— Transcript della presentazione:

1

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

3 a.a. 2004/05Tecnologie Web2 ARCHITETTURE Parte I: –L’evoluzione del Client/Server – Database servers e Fat client – Architetture Multi-Tier – CORBA

4 a.a. 2004/05Tecnologie Web3 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

5 a.a. 2004/05Tecnologie Web4 Prerequisiti Concetti di object oriented design (breve accenno durante il corso) MS windows (utente) Internet WWW (utente)

6 a.a. 2004/05Tecnologie Web5 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

7 a.a. 2004/05Tecnologie Web6 L’evoluzione del Client/Server CLIENT SERVER PC stand alone PC networking End User HOST solution MINI solution Enterprise

8 a.a. 2004/05Tecnologie Web7 Allocazione Delle Componenti Data Management Logic/ Control Presentation SERVER CLIENT NETWORK

9 a.a. 2004/05Tecnologie Web8 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.

10 a.a. 2004/05Tecnologie Web9 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.

11 a.a. 2004/05Tecnologie Web10 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…)

12 a.a. 2004/05Tecnologie Web11 Classificazione delle soluzioni Client/Server

13 a.a. 2004/05Tecnologie Web12 Le “ere” del Client/Server Da: Byte Aprile 95

14 a.a. 2004/05Tecnologie Web13 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

15 a.a. 2004/05Tecnologie Web14 Monoliti (IT stovepipe) - II Enterprise User interface Logic Data Management

16 a.a. 2004/05Tecnologie Web15 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

17 a.a. 2004/05Tecnologie Web16 Architetture client/server - III Enterprise User interface Logic Data Management Client Server

18 a.a. 2004/05Tecnologie Web17 Architetture client/server - II Svantaggi: 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

19 a.a. 2004/05Tecnologie Web18 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 Client Nuovo Client Server Adapter

20 a.a. 2004/05Tecnologie Web19 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 OracleDB2 MS SQL Server SybaseInformix Database Servers

21 a.a. 2004/05Tecnologie Web20 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 Oracle Esempio di prodotti Ethernet

22 a.a. 2004/05Tecnologie Web21 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

23 a.a. 2004/05Tecnologie Web22 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à

24 a.a. 2004/05Tecnologie Web23 RDBMS: Stored Procedures Utilizzando comandi SQL l'interazione client/server è elevata: declare C cursor for select * from T where... open C fetch C update... ClientServer declare open fetch update fetch update fetch update

25 a.a. 2004/05Tecnologie Web24 RDBMS: Stored Procedure Con 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" ClientServer execute Attenzione: le Stored Procedure non sono portabili da un RDBMS all’altro!

26 a.a. 2004/05Tecnologie Web25 Replicazioni Asincrone Dati primari Dati primari locali London Tokio New York DB Dati replicati

27 a.a. 2004/05Tecnologie Web26 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)

28 a.a. 2004/05Tecnologie Web27 nReplicazione di testata e dettagli di un ordine di acquisto order 100 item A item B DATI PRIMARI order 100 item A item B not yet available DATI REPLICATI Integrità referenziale

29 a.a. 2004/05Tecnologie Web28 New York London Tokio Singapore SydneyHong Kong Glasgow Rome Hamburg Routing delle repliche

30 a.a. 2004/05Tecnologie Web29 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.

31 a.a. 2004/05Tecnologie Web30 Middleware Middleware: software di sistema che permette l’interazione a livello applicativo fra programmi in un ambiente distribuitoMiddleware: software di sistema che permette l’interazione a livello applicativo fra programmi in un ambiente distribuito Facilitano e gestiscono interazioni tra applicazioni su piattaforme eterogenee –LAN ristrette –Complesse applicazioni –Utilizzo di tecnologie Web

32 a.a. 2004/05Tecnologie Web31 Tipologie di Middleware  TP monitor (OLTP)  Message Oriented (MOM)  Publish/Subscribe  Object Request Broker (ORB)   Object Transaction Monitor (OTM)

33 a.a. 2004/05Tecnologie Web32 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 Share CICSIMSTuxedoEncina/TxSeries MS Transaction Server TIBCO Etx TP Monitors (OLTP: On Line Transaction Processing)

34 a.a. 2004/05Tecnologie Web33 TP Monitors Servizio DATI Applicazioni “Service Oriented”

35 a.a. 2004/05Tecnologie Web34 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).

36 a.a. 2004/05Tecnologie Web35 Normalizzazione dei Servizi Gli obiettivi della normalizzazione sono quelli di migliorare la chiarezza del disegno e di ridurre, o in alcuni casi eliminare, la ridondanza della logica Si possono identificare cinque forme normali come indicato in figura. Le prime tre forme normali implicano un livello di strutturazione del codice utilizzando modelli di programmazione tradizionali Le ultime due forme normali introducono il concetto di incapsulamento dei dati e quindi stanno alla base dei paradigmi object-oriented Le cinque forme normali del partizionamento applicativo I I servizi hanno una interfaccia formale e pubblica Ciascuna funzione business appare in un servizio Ciascun funzione business appare in un solo servizio I servizi incapsulano i dati Le applicazioni incapsulano i dati II III IV V Un modulo software è normalizzato se aderisce almeno alla prima forma normale. Source: Gartner Group

37 a.a. 2004/05Tecnologie Web36 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

38 a.a. 2004/05Tecnologie Web37 Proprietà “ACID” Una transazione deve essere: –Atomica –Consistente –Isolata –Durevole

39 a.a. 2004/05Tecnologie Web38 Funnelling (1)

40 a.a. 2004/05Tecnologie Web39 Funnelling (2)

41 a.a. 2004/05Tecnologie Web40 DesktopWork-groupDepart-mentDivisionEnter-prise 1 user 2 users 100s1000s10,000s Internet 100,000s Shared Data Connections Security Context Multithread Multithreading Load Balancing Multinode Msg Q’ing Multisite High Avail Fonte: Microsoft La scalabilità dei sistemi

42 a.a. 2004/05Tecnologie Web41 Politiche di disegno di sistemi OLTP Liberare le risorse allocate ai client quanto prima Uso delle transazioni Riuso delle risorse da un client all’altro (pool risorse) Uso delle risorse ridotto all’essenziale da parte del client Disegno di servizi (o oggetti) elementari

43 a.a. 2004/05Tecnologie Web42 Architetture Two-Tiers e Three-Tiers Market Share DB Market Share DB minore uso delle risorse suddivisione più razionale dei compiti livello intermedio

44 a.a. 2004/05Tecnologie Web43 Architetture Multi-Tier Database Servers NC. NetPC PC Client Mobile Mail/GroupwareServers MainframeSystems Interfaccia Utente Logica Applicativa Dati

45 a.a. 2004/05Tecnologie Web44 LogicaApplicativa Web+ActiveX o applet Java Web+script lato server (ASP, JSP o servlet) Visual Basic, C++, Delphi Client/Server Lotus Notes, Exchange Groupware Applicazioni real-time batch, OLTP, M&Q Persistenza dei dati Architetture Three-Tier: molti tipi di interfacce utente, la stessa applicazione

46 a.a. 2004/05Tecnologie Web45 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..

47 a.a. 2004/05Tecnologie Web46 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)

48 a.a. 2004/05Tecnologie Web47 Architetture three-tier - III Business Rules Enterprise User interface Presentation layer Logic Business layer Data Management Data layer Data Service Data Service Data Service Business Rules Business Rules Motif Client Windows Client Telephony Client Mac Client

49 a.a. 2004/05Tecnologie Web48 Architetture three-tier - IV User Interface Application Logic DB XML Documents Data providers Service provider Service consumer Directory service

50 a.a. 2004/05Tecnologie Web49 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)

51 a.a. 2004/05Tecnologie Web50 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

52 a.a. 2004/05Tecnologie Web51 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)

53 a.a. 2004/05Tecnologie Web52 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

54 a.a. 2004/05Tecnologie Web53 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 Data Components Logic Rules

55 a.a. 2004/05Tecnologie Web54 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

56 a.a. 2004/05Tecnologie Web55 Architetture n-Tier - II Infrastructure services –forniscono funzionalità supplementari alle componenti dell’applicazione (messaging, supporto alle transazioni, …) Data layer: –livello dei dati dell’applicazione

57 a.a. 2004/05Tecnologie Web56 Architetture n-Tier - III Browser DB XML Documents Presentation Logic Business Logic Services Application client Firewall

58 a.a. 2004/05Tecnologie Web57 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 Web Server Business logic Browser utente HTTP

59 a.a. 2004/05Tecnologie Web58 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) Web Server Local File System /htdocs/hello.html Request: http://patzer/hello.html Response: HTML code Browser utente

60 a.a. 2004/05Tecnologie Web59 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) Web Server Business logic Request: http://www.di.unito.it/service1.html Response: pagina HTML di risposta, con eventuali link e bottoni per continuare interazione Browser utente

61 a.a. 2004/05Tecnologie Web60 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)

62 a.a. 2004/05Tecnologie Web61 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)

63 a.a. 2004/05Tecnologie Web62 Message Oriented Middleware (MOM) IBM MQSeries MS Message Queue ServerMS Message Queue Server SonicSonic  consegna garantita  disaccoppiamento mittente-destinatario

64 a.a. 2004/05Tecnologie Web63 Publish/Subscribe TIBCO /Rendezvous BEA TuxedoBEA Tuxedo in futuro Microsoft.NETin futuro Microsoft.NET  trasmissione uno-molti in “multicasting”  “push technology” Internet  applicazione del paradigma “event-driven”

65 a.a. 2004/05Tecnologie Web64 Publish & Subscribe Publish “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”

66 a.a. 2004/05Tecnologie Web65 Modelli di comunicazione fra programmi Conversational Request/Reply (RPC) Program A Program B Call Return Program A Program B Message Passing ReceiveSend Message Queuing Queue EnqueueDequeue Publish and Subscribe Program C Publish Subscribe Program A Program B Program A Program B Program A Program B Indipendenza dalla locazione fisica del destinatario Indipendenza dalla locazione fisica e dalla disponibilità immediata del destinatario Indipendenza dalla locazione fisica, dalla disponibilità immediata, dall’identità e dal numero di destinatari

67 a.a. 2004/05Tecnologie Web66 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 Interface stub Interface proxy Client Server Service-oriented or Event-driven SourceSink 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

68 a.a. 2004/05Tecnologie Web67 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

69 a.a. 2004/05Tecnologie Web68 Approccio ad Oggetti

70 a.a. 2004/05Tecnologie Web69 Approccio ad Oggetti (1) Incapsulamento di dati e regole (attributi e metodi di una Classe) Ereditarietà Polimorfismo

71 a.a. 2004/05Tecnologie Web70 Approccio ad Oggetti (2) Librerie di classi e Frameworks (infrastrutture di classi) Legami (binding) statici e dinamici Relazioni tra gli oggetti: –specializzazione –associazione –aggregazione

72 a.a. 2004/05Tecnologie Web71 Relazioni fra gli oggetti Generalizzazione / Specializzazione Associazione Aggregazione File Directory

73 a.a. 2004/05Tecnologie Web72 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

74 a.a. 2004/05Tecnologie Web73 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

75 a.a. 2004/05Tecnologie Web74 Object Request Broker (ORB) Market Share

76 a.a. 2004/05Tecnologie Web75 DistributedOperatingEnvironment Integrated Storage Business Process User Interface & Navigation Tools Microsoft COM/DCOM OMG CORBA Object Request Brokers

77 a.a. 2004/05Tecnologie Web76 CORBA (Common Object Request Broker Architecture) Uno standard per architetture distribuite ad oggetti definito dall’Object Management Group (OMG) http://www.omg.org/

78 a.a. 2004/05Tecnologie Web77 CORBA: Interazione client-oggetti IDL Client Obj Impl IDL ORB IDL Client IDL ORB Obj Impl

79 a.a. 2004/05Tecnologie Web78 Creazione dei Client e delle Object Implementation IDL Interface Definitions Implementation Installation Client Stubs Interface Repository Implementation Repository Implementation Skeletons Client Object Implementation Accesses Includes Describes Includes Copyright © 1994, Object Management Group. [78]

80 a.a. 2004/05Tecnologie Web79 Object management architecture

81 a.a. 2004/05Tecnologie Web80 Accesso trasparente alla locazione

82 a.a. 2004/05Tecnologie Web81 Interface Definition Language (IDL) Moduli Interfacce (parti dichiarative delle classi) Operazioni (metodi) Tipi di dati

83 a.a. 2004/05Tecnologie Web82 IDL - tipi elementari boolean char octet enum short unsigned short long unsigned long float double any

84 a.a. 2004/05Tecnologie Web83 IDL - tipi composti stringstring arrayarray [10] sequencesequence struct union

85 a.a. 2004/05Tecnologie Web84 IDL - dichiarazione di tipi typedef struct { short ORA; short MINUTI; } TEMPO; typedef sequence TESTO;

86 a.a. 2004/05Tecnologie Web85 IDL - eccezioni exception EXC1 {long N}; void MET1() raises (EXC1);

87 a.a. 2004/05Tecnologie Web86 IDL - interfacce interface CLIENTE: PERSONA { attribute short CODICE; long CREDITO (); }; … CLIENTE::CREDITO()...

88 a.a. 2004/05Tecnologie Web87 Esempio di IDL interface Persona { readonly attribute Gender sesso; readonly attribute Date datanascita; attribute string nome; }; interface Impiegato : Persona { readonly attribute ssn; void aggiungiImpiegato (Impiegato imp); void eliminaImpiegato (Impiegato imp); short numImpiegati (); Impiegato Impiegato (short indice); };

89 a.a. 2004/05Tecnologie Web88 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

90 a.a. 2004/05Tecnologie Web89 Dall’HTML statico alle applicazioni Client/Server 1

91 a.a. 2004/05Tecnologie Web90 CORBA e Internet

92 a.a. 2004/05Tecnologie Web91 HTML Dinamico Interne t (htpp) WebServer HTML JSP servlet BusinessObjects DATI servlet browser 1. richiesta.jsp 4. ritorna html 2. richiesta dati 3. generazione html Tier 1 Tier 2 Tier 3 Application server

93 a.a. 2004/05Tecnologie Web92 CORBA services Naming Lifecycles Event Notification Persistence Concurrency Control Relationships Transactions Collections Externalization Time Security Query Service Licensing Trader Change Management Properties

94 a.a. 2004/05Tecnologie Web93 Servizio di Naming Ricerca di un oggetto per nome “Name binding” associazione nome  riferimento dell’oggetto Nomi composti per specificare spazi di nomenclatura: es: “regione NordOvest”, “distretto di Torino”, “abbonato Mario Rossi”

95 a.a. 2004/05Tecnologie Web94 Servizio di Naming (2) NamingContext –resolve –bind –list –destroy –bind_new_context BindingIterator –next_one –destroy

96 a.a. 2004/05Tecnologie Web95 Servizio di Life Cycle Permette di creare oggetti per mezzo di “factory objects” che espongono il metodo “create_object” Metodi di tutti gli oggetti con LifeCycle: “copy”, “move”, “remove” Permette la gestione automatica di relazioni referenziali e di contenimento fra oggetti (es. spostamento o cancellazione di tutti gli oggetti in una lista)

97 a.a. 2004/05Tecnologie Web96 Servizio di Event Oggetti “fornitori” e “consumatori” di eventi Event channel Modelli “push” e “pull” Tipi di eventi e sottoscrizioni SupplierEvent ChannelConsumer

98 a.a. 2004/05Tecnologie Web97 Servizio di Transactions OTS - Object Transaction Service Oggetto “Current” che espone i metodi “begin”, “commit”, “rollback” di una transazione Oggetti “Resource” (una risorsa coinvolta nella transazione) Oggetto “Coordinator”: il coordinatore delle transazioni

99 a.a. 2004/05Tecnologie Web98

100 a.a. 2004/05Tecnologie Web99 Estensioni di CORBA 3.0 Message Oriented Middleware Interfacce multiple Modello componenti (CCM) Java Bindings Passaggio parametri per valore (Valuetypes) Interoperabilità con DCOM Minimum CORBA Realtime CORBA