MIDDLEWARE e CORBA. Corso di Architetture Distribuite e Servizi di Rete. Antonio Corradi & Paolo Bellavista MIDDLEWARE

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "MIDDLEWARE e CORBA. Corso di Architetture Distribuite e Servizi di Rete. Antonio Corradi & Paolo Bellavista MIDDLEWARE"

Transcript

1 Università degli Studi di Bologna MASTER integratori di Sistema MIDDLEWARE e CORBA Corso di Architetture Distribuite e Servizi di Rete Antonio Corradi & Paolo Bellavista Middleware e CORBA 1 MIDDLEWARE Definizione di MIDDLEWARE Insieme degli strumenti che permettono la integrazione di diverse applicazioni e servizi da utilizzare in ambienti aperti Middleware comprendono strumenti per lo sviluppo fino al livello di applicazione RPC middleware Chiamate di Procedura Remote come strumento di invocazione di livello applicativo tra ambienti diversi Middleware e CORBA 2

2 MIDDLEWARE Lo Strato di software che risiede tra la applicazione e i componenti di rete, di sistema operativo locale, di hardware eterogeneo, di aree di applicazioni diverse, ecc. Lo strato di disaccoppiamento tra i livelli di sistema consente la semplificazione del progetto sia della parte applicativa sia del supporto Middleware e CORBA 3 MIDDLEWARE Il Middleware viene spesso invocato in modo trasparente e fornisce l accesso uniforme a funzioni locali eterogenee Spesso viene usato per integrare sistemi legacy preesistenti e necessari alla logica aziendale Spesso si propone come uno standard (di fatto o di comitato) per una comunità specifica Middleware e CORBA 4

3 SERVIZI di un MIDDLEWARE MIDDLEWARE forniscono servizi differenziati In senso esteso per molte aree diverse Presentation Management Computation Information Management Communication Control System Management (stampa, grafica, GUI, interazione) (procedure comuni, servizi caratteri, internazionalizzazione, sorting) (file manager, record manager, database manager, log Manager, ) (messaging, RPC, message queue, mail, electronic data interchange ) (thread manager, scheduler, transaction manager, ) (accounting, configuration, security, performance, fault management, event handling) Middleware e CORBA 5 MIDDLEWARE come livelli di sistema MIDDLEWARE tra Applicazione e Sistema Operativo Applicazione Domain-specific Middleware Service Common Middleware Services Distribution Middleware Host Infrastructure Middleware Sistema Operativo Hardware Middleware e CORBA 6

4 MIDDLEWARE come livelli di sistema Host Infrastructure Middleware Livello che incapsula e prepara i servizi locali per la distribuzione e per facilitare la comunicazione Esempi: JVM,.NET, altri modelli locali Applet e Applicazioni Java Classi Base Adattatore Browser S.O. Hw Estensione di Classi di Java Java Virtual Machine Interfaccia di portabilità Adattatore Browser S.O. Hw Adattatore Browser S.O. Hw Adattatore Browser S.O. Hw Si forniscono delle API che permettono di avere un supporto locale unificato per i diversi sistemi Interconnessione via Rete Middleware e CORBA 7 MIDDLEWARE come livelli di sistema Distribution Middleware Livello che fornisce i modelli della programmazione distribuita e facilita le applicazioni distribuite configurando e gestendo le risorse distribuite Esempi: RMI, CORBA, DCOM, SOAP, Sistemi che permettono una più facile comunicazione e coordinamento dei diversi nodi che partecipano al sistema introducendo un modello delle risorse e API di comunicazione secondo un modello concettuale altre funzionalità accessorie per la comunicazione supporto di nomi, di discovery, Middleware e CORBA 8

5 MIDDLEWARE come livelli di sistema Common Middleware Services Servizi aggiuntivi di più alto livello per facilitare la vita del progettista applicativo e per consentire una programmazione orientata ai componenti fornendo supporto Esempi: CORBAServices, J2EE,.NET Web services Alcune funzioni addizionali per consentire operazioni facilitate spesso ispirate ad una architettura comune ed a un modello di supporto Molti servizi addizionali per componenti eventi, logging, streaming, sicurezza, fault tolerance, Middleware e CORBA 9 MIDDLEWARE come livelli di sistema Domain-specific Middleware Service Insieme di livelli applicativi dedicati a domini diversi Esempi: Alcuni gruppi di lavoro stanno definendo funzionalità ad-hoc per settori diversi con obiettivi anche molto differenziati di standardizzazione Task Force di lavoro in ambito OMG Electronic Commerce TF, Finance (banking and insurance) TF, Life Science Research Domain TF, Syngo Siemens Medical Engineering Group, Boeing Bold Stroke basato su CORBA Middleware e CORBA 10

6 CLASSIFICAZIONE MIDDLEWARE MIDDLEWARE RPC middleware Message Oriented Middleware (MOM) Distributed Transaction Processing (TP) Monitor Database Middleware Distributed Object Computing (DOC) Middleware Adaptive & Reflective Middleware Altri special purpose: Mobile & QoS Multimedia Middleware Agent-based Middleware Middleware e CORBA 11 MIDDLEWARE!? Wide Area Distributed Middleware (Web) Middleware che permette l accesso in lettura e anche scrittura ad un insieme globale di informazioni Le operazioni avvengono per un sistema globale Moltissimi domini amministrativi di gestione Moltissimi utenti Moltissimi host partecipanti e Molta eterogeneità di banda, interconnessione, Questi non sono veri e propri middleware ma forse solo sistemi di accesso e messa in linea di informazioni Web come esempio principe Middleware e CORBA 12

7 RPC MIDDLEWARE RPC come strumenti per il C/S Interface Definition Language (IDL) per l accordo Sincronicità: il cliente bloccato in modo sincrono bloccante in attesa della risposta dal Server Gestione eterogeneità dei dati Uso di Stub per la Trasparenza Binding spesso statico (o poco dinamico) Modello un po rigido, poco scalabile e replicabile con QoS Il server deve essere presente e prevedere i processi necessari in modo esplicito Non si tiene conto di eventuali ottimizzazioni nell uso delle risorse Middleware e CORBA 13 MOM MIDDLEWARE Message Oriented Middleware (MOM) La distribuzione dei dati e codice avviene attraverso lo scambio di messaggi Scambio messaggi tipati e non tipati sia sincrono sia asincrono con strumenti ad-hoc ampia autonomia tra i componenti asincronicità e persistenza delle azioni gestori (broker) con politiche diverse e QoS diverso facilità nel multicast, broadcast, publish / subscribe Esempio: Middleware basati su messaggi, code e gestori MQSeries IBM, MSMQ Microsoft, JMS SUN Middleware e CORBA 14

8 OO e DOC MIDDLEWARE Distributed Object Computing (DOC) Middleware La distribuzione dei dati e codice avviene attraverso richieste di operazioni tra clienti e servitori remoti Uso di oggetti come framework e di un broker come intermediario nella gestione delle operazioni il modello ad oggetti semplifica il progetto il broker fornisce i servizi base e molti servizi addizionali alcune operazioni si possono fare in modo automatico la integrazione di sistemi è facilitata e incentivata la tecnologia open source è favorita Esempi: CORBA,.NET e COM, Java Middleware e CORBA 15 MIDDLEWARE Adaptive & Reflective Middleware In alcuni casi la visibilità dei livelli sottostanti può diventare fondamentale per raggiungere ottimizzazione Uso di middleware che si possono adattare alla applicazione specifica anche in modo dinamico, reattivo e radicale variazioni statiche dipendenti dal componente variazioni dinamiche dipendenti dal sistema Con la Riflessività, le politiche di azione sono espresse e visibili nel middleware stesso e si possono cambiare come componenti del sistema Si raggiunge adattamento e flessibilità durante l esecuzione Esempi: ancora non molti diffusi Middleware e CORBA 16

9 MIDDLEWARE: AD OGGETTI - DOC Sistemi ad oggetti APERTI Object-Oriented Relazioni cliente/servitore nel distribuito vincolata nell ambito di sistemi ad oggetti Obiettivo: tutte le risorse (oggetti o meno) devono essere a disposizione di tutti gli utilizzatori, comunque siano stati specificate e da chiunque siano rese disponibili Sistema multi-linguaggio e di integrazione con componenti legacy anche non ad oggetti MOLTI PROGETTI simili in questa direzione Open Software Foundation Distributed Computing Environment DCE - RPC Ansa Ansaware - Ambiente distribuito e standard BBN CHRONUS - Ambiente di servizi con ereditarietà Middleware e CORBA 17 MIDDLEWARE: ETEROGENEITÀ Possibile infrastruttura per la interazione tra ambienti diversi supera i problemi introdotti da approcci ad-hoc funzioni di conversione custom conversione in formato generico wrapper Cliente Servitore protocollo comune Middleware GUI DSOM Sist. Operativo Oggetti Servizi SQL Mail ORB Groupware DSOM snmp CMIP DME DSOM DBMS NOS Directory Security DSOM RPC Messaggi Trasporto TCP/IP SNA Sist. Operativo NetBIOS IPX/SPX Middleware e CORBA 18

10 MIDDLEWARE: CORBA OMG- Object Management Group CORBA creato nel 1989 con 440 aziende Microsoft, Digital, HP, NCR, SUN, OSF, etc. con l'obiettivo di creare un sistema di gestione di una architettura distribuita Common Object Request Broker Architecture CORBA standard v1 1991, v v2 1996, v Orbix SunOS Solaris, Iris, Windows NT, HP/UX, AIX, OSF/1, UnixWare DSOM IBM Middleware e CORBA 19 MIDDLEWARE: CORBA STANDARD SISTEMI APERTI AD OGGETTI modelli ad oggetti diversi con possibilità di integrazione e interazione reciproca completa anche provenendo da linguaggi ed ambienti diversi definizione di una interfaccia per oggetto definizione della interazione tra oggetti bus per integrazione di oggetti progettati in linguaggi diversi definizione della interazione anche tra sistemi diversi con diversi gestori Middleware e CORBA 20

11 ENTITÀ da mettere in relazione: cliente e implementazione di un oggetto per il servizio oggetto richiesta MIDDLEWARE: CORBA entità che fornisce servizi meccanismo per manifestare esigenza di un servizio tipo entità per classificare gli oggetti interfaccia descrizione delle operazioni possibili per un insieme di oggetti operazione servizio con nome che può essere richiesto ad un oggetto Middleware e CORBA 21 MIDDLEWARE: CORBA Common Object Request Broker Architecture CORBA come ambiente comune anche Object Management Architecture Il cuore è il gestore dei nomi (broker) che consente i collegamenti in modo statico e dinamico tra le entità Object Request Broker (ORB) controllo allocazione e visibilità di oggetti controllo dei metodi e della comunicazione controllo di servizi accessori disponibili automaticamente nella OMA gestione facilitata dei servizi Middleware e CORBA 22

12 CORBA come BUS Struttura ORBA ORB come un bus di interconnessione Tutti gli oggetti applicativi gestiti possono appartenere ad ambienti diversi e devono potere comunicare senza un riprogetto Applications Object Middleware e CORBA 23 CORBA come BUS ORB per la comunicazione degli oggetti locali ed anche per la comunicazione tra ORB diversi In un solo sistema CORBA o in più sistemi OMA coordinando broker diversi tra loro Oggetti Applicativi Oggetti Applicativi Cliente logico Servitore Cliente logico Servitore dinamico dinamico Object Request Broker ORB 1 ORB 2 Middleware e CORBA 24

13 Object Management Architecture Ogni componente può legarsi agli altri, anche non noti, usando il servizio di uno o più ORB (anche non noti a priori) Insieme di componenti addizionali di ambiente Object Services o CORBA Services Operazioni fondamentali per oggetti naming e trading service event e notification service Oltre ad operazioni ulteriori (o servizi) Per la gestione del tempo di vita, relazionali, transazioni, controllo concorrenza, sicurezza Middleware e CORBA 25 Object Management Architecture Altri componenti addizionali di ambiente Common Facilities CF (orizzontali) Insieme di funzionalità specifiche Interfaccia utente (client-site), Management Sistema, Informazioni, Task (server-site) Domain Interfaces (verticali) funzionalità dedicate ad aree applicative, ad es. manifacturing, telecommunications, electronic commerce, transportation, business objects, healthcare, finance, life science, Application Interfaces Non standardizzate in alcun modo e dipendenti dalla applicazione Middleware e CORBA 26

14 Object Management Architecture OMA Ambiente Object Framework Middleware e CORBA 27 COMPONENTI DI CORBA I componenti essenziali della architettura OMA e di CORBA * Object Request Broker (ORB) * Interface Definition Language (IDL) * Basic Object Adapter (e altri) (BOA) * Static Invocation Interface (SII) * Dynamic Invocation Interface (DII) * Interface Repository (IR) Middleware e CORBA 28

15 COMPONENTI DI CORBA Object Request Broker (ORB) deve coordinare la invocazione di servizi locali e remoti (dinamico) individuare l implementazione di un oggetto come servitore ad una richiesta (object location) preparare il servitore a ricevere la richiesta (object creation, activation & management) trasferire la richiesta dal cliente al servitore restituire la risposta al cliente Oggetti Applicativi Clienti Servitori Cl1 Srv1 ORB Middleware e CORBA 29 COMPONENTI DI CORBA Interface Definition Language (CORBA IDL) deve coordinare la identificazione dei servizi richiesti e offerti, locali e remoti (statico) Si devono associare le richieste di operazioni e le offerte di servizio Sia i servitori sia i clienti devono potere identificarsi e rendersi noti reciprocamente Si fa ampio uso della esperienza degli IDL già sviluppati Purtroppo IDL consente solo una identificazione ed un legame previsto e riconosciuto staticamente. E se volessimo legami dinamici?? Middleware e CORBA 30

16 CORBA: VISIONE DINAMICA Elementi in gioco: visione complessiva Cliente Implementazione dell'oggetto Invocazione Stub Interfaccia Scheletro Scheletro dinamica IDL ORB statico dinamico Adattatore d'oggetto Nucleo dell'orb Nuovo, introdotto con CORBA 2.0 Identica interfaccia per tutte le implementazioni di ORB Possibili adattatori d'oggetto multipli Una stub ed uno scheletro per ogni tipo d'oggetto Interfaccia ORB-dipendente interfaccia di chiamata verso l'alto interfaccia di chiamata normale Middleware e CORBA 31 CORBA IDL per MULTILINGUAGGIO Interface Definition Language (CORBA IDL) deve coordinare la identificazione dei servizi statici richiesti e offerti in diversi linguaggi //OMG IDL interface Factory { Object create(); }; Questa interfaccia consente di riferire un oggetto di tipo factory e di chiedere la operazione create (senza parametri di in e out) di un oggetto riconosciuto Con IDL si devono definire nuove interfacce e nuovi tipi secondo necessità e farli riconoscere e registrare Middleware e CORBA 32

17 CORBA IDL -> > STUB E SKELETON Interface Definition Language (CORBA IDL) permette di generare nei diversi linguaggi componenti automatiche di appoggio (stub e skeleton) per la funzionalità dei clienti e servitori Lo stub permette di lavorare sul messaggio dalla parte del cliente (marshalling) agendo come proxy del cliente Lo skeleton collabora con l ORB per prendere la richiesta e adattarla al server (unmarshalling) girandogli la richiesta In questo modo lavoriamo producendo un legame statico tra interfaccia e cliente e servitore. Entrambi sono legati alla interfaccia dallo stub e skeleton creati prima della esecuzione Middleware e CORBA 33 CORBA ADAPTER Adattatore (Object Adapter) permette di superare disomogeneità e differenze tra la interfaccia assunta dal chiamante e quella attesa dal servitore Ha compiti tipici: funzionalità di registrazione dell oggetto generazione dei riferimenti esterni all oggetto attivazione dei processi interni server e dell oggetto stesso demultiplexing delle richieste in modo da disaccoppiarle invio delle richieste (upcall) agli oggetti registrati I primi adattatori erano BOA (Basic), poi POA (Portable) Middleware e CORBA 34

18 OBJECT REPOSITORY in CORBA Interface Repository consente di accedere a tutti i tipi di dati IDL e di accedere alle interfacce esportate dagli oggetti presenti e disponibili durante la esecuzione Le interfacce sono traslate nei linguaggi di programmazione diversi in cui i componenti sono progettati e compilati (binding statico) Ci sono casi in cui l approccio statico non è attuabile: un gateway che permette di accedere alle interfacce CORBA di un ambiente che non può essere ricompilato ogni volta che si aggiunge una nuova interfaccia IR permette di avere le interfacce presenti dinamicamente e di decidere al momento della esecuzione (binding dinamico) Middleware e CORBA 35 SISTEMI CORBA DIVERSI Definizione (dalla versione 2) di Protocolli InterORB per stabilire come fare interagire diversi sistemi CORBA protocollo per interoperabilità ORB-to-ORB General Inter-ORB Protocol (GIOP) Molto diffuso per la interoperabilità per Internet su TCP/IP Internet Inter-ORB Protocol (IIOP) Oggetti Applicativi Cliente Servitore ORB 1 protocolli GIOP / IIOP ORB 2 Middleware e CORBA 36

19 CORBA ARCHITETTURA Visione di insieme della architettura Middleware e CORBA 37 ORB funzioni Core ORB coordina le richieste degli oggetti clienti di competenza, in modo trasparente da: posizione e implementazione dell oggetto remoto (indipendenza dal linguaggio) comunicazione specifica usata e disponibile Uso di riferimenti ad oggetti esistenti (non creati da CORBA) ottenuti attraverso: creazione esplicita esterna di oggetto utilizzo di directory di oggetti conversione di riferimenti in stringhe e viceversa (oggetti riferiti e traslati in stringhe, poi riottenuti) Necessità di servizi di nome (Trading e Naming service) Middleware e CORBA 38

20 CORBA- IDL CORBA IDL interfacce come insiemi di metodi ed attributi distinzione tra definizione e implementazione ereditarietà multipla delle interfacce definizione eccezioni gestione automatica degli attributi mappaggi per linguaggi diversi ed ambienti diversi Il compilatore può ottenere automaticamente stub per clienti/servitori anche usando linguaggi diversi Middleware e CORBA 39 CORBA- IDL INTERFACE DEFINITION LANGUAGE (OMG IDL) introdotti per garantire flessibilità nella distribuzione su piattaforme eterogenee Sono linguaggi dichiarativi per interfacce e dati Molti IDL diffusi sono procedurali * OSI ASN.1 / GMDO * ONC XDR (SUN RPC) * Microsoft ODL CORBA IDL è un linguaggio object-oriented (derivato dal C++) Ovviamente i diversi IDL sono non compatibili tra di loro, anche se spesso sono diversi solo per questioni di sintassi e di sistemi di identificazione e nomi delle entità Middleware e CORBA 40

21 BINDING STATICO in CORBA Static Invocation Interface (SII) Il compilatore e gli strumenti risolvono le chiamate prima della esecuzione Tutte le invocazioni sono controllate in anticipo e sicure nessun controllo dinamico nei confronti della interfaccia Il cliente si lega allo stub e fa la richiesta dopo essersi collegato all ORB (invocazione sincrona) Il servitore si è legato allo skeleton e viene attivato dall object adaptor (POA) per rispondere alla richiesta In caso il (un) servitore non sia attivo, il POA lo attiva e gli passa la richiesta Middleware e CORBA 41 BINDING DINAMICO in CORBA Dynamic Invocation Interface Dynamic Skeleton Interface (DII) e (DSI) necessari per inviare le richieste e per fornire operazioni senza prevedere staticamente legame con una interfaccia cioè per legarsi ad oggetti che non esistono al momento della compilazione comportamento DINAMICO Il cliente si appoggia a run-time sull interface repository per la conoscenza dell interfaccia d oggetto di interesse In questo caso si possono assumere invocazioni meno sincronizzate e più varie tra il cliente e il servitore (forme diverse di asincronicità) Middleware e CORBA 42

22 BINDING DINAMICO in CORBA (DII) API per comporre la richiesta e pseudo oggetto Request pseudo interface Request {// Pseudo IDL Status add_arg (in Identifier name, in TypeCode arg_type, in void *value, in long len, in Flag arg_flag ); Status invoke (in Flags invoke_flags // flag invocazione); Status delete (); Status send (in Flags invoke_flags // flag invocazione); Status get_response (in Flags response_flags //flag risposta); } La richiesta viene preparata e la chiamata dinamica comporta un costo più elevato rispetto alla statica Anche modalità oltre la sincrona, Deferred Synchronous Invocation e Oneway Invocation Middleware e CORBA 43 BINDING DINAMICO in CORBA (DSI) Per potere invocare la richiesta Request in modo dinamico un metodo (invoke) permette la invocazione dinamica pseudo interface ServerRequest {// Pseudo IDL readonly attribute Identifier operation_name; readonly attribute OperationDef operation_definition; void parameters(inout NVList params); Context ctx(); void set_result(in Any val); void set_exception(in Any val); }; L oggetto server deve implementare una interfaccia che prevede la invoke da parte dell ORB Controllo dinamico della correttezza dei parametri Middleware e CORBA 44

23 SEMANTICA INVOCAZIONI in CORBA La normale modalità è la sincrona bloccante In caso di guasti o problemi, il cliente riceve una eccezione di quelle previste dalla interfaccia Semantica at-most-once La invocazione sincrona statica costa meno della dinamica corrispondente Altre modalità per la sola invocazione dinamica: Oneway Invocation nessuna risposta (semantica best effort) Deferred Synchronous risposta da ritrovare in tempi successivi con attesa solo quando necessario (at-most-once) Middleware e CORBA 45 COMPONENTI CORBA: ADATTATORE Gli Adattatori sono i componenti responsabili della flessibilità di CORBA I molteplici adattatori devono arrivare alla implementazione dei diversi oggetti servitori e comandare la esecuzione concreta Si parla di servant per le attività che lavorano sugli oggetti concreti per fornire le funzioni del server Implementazione dell'oggetto Attiva implementazione Metodi Registra Attiva Invoca Accede implementazione l'oggetto il metodo ai servizi del BOA Basic Object Adapter Scheletro ORB Middleware e CORBA 46

24 COMPONENTI CORBA: ADATTATORE Gli Adattatori controllano la esecuzione del server astratto attraverso i servant concreti che lavorano sul codice del servizio MOLTI MODI DI ATTIVAZIONE NEL SERVER attivazione per ogni richiesta (thread_per_request) un processo viene creato nell'oggetto per servizio attivazione iniziale di un pool (pool di thread) ogni oggetto riceve il suo processo da un pool creato inizialmente senza il costo della creazione attivazione per sessione (thread_per_session) ogni cliente ha un processo dedicato alla interazione Anche altre modalità: un thread per ogni servant una sola attivazione per più oggetti server (shared server) contemporaneamente Middleware e CORBA 47 Attivazione THREAD-PER PER-REQUESTREQUEST ThreadB ThreadA ThreadC Servitore Ogni richiesta riceve un thread attivato by-need generazione di thread ObjectAdapter Costo elevato della attivazione che pesa su ogni operazione Client1 Client2 Più Servant Capacità di Esecuzione Middleware e CORBA 48

25 Pool di Thread ThreadB ThreadA Attivazione THREAD-POOL Coda Richieste ThreadC ObjectAdapter Servitore generazione di thread Ogni richiesta riceve un thread da un pool di processi creati prima In caso non ce ne siano, si aspetta il primo libero Client1 Client2 Più Servant Costo inferiore, ma anche elevata attesa in caso di traffico non previsto Capacità di Esecuzione Richieste in Coda Middleware e CORBA 49 Thread1 Attivazione THREAD-PER PER-SESSIONE Generazione su richiesta Coda Richieste Thread3 Thread2 Servitore generazione di thread Ogni cliente riceve un thread attivato all inizio della sessione di lavoro ObjectAdapter Si limita il parallelismo del servizio Client1 Client2 Più Servant Richieste in Coda Client3 Middleware e CORBA 50

26 Attivazione THREAD-PER PER-SERVANT ServantA ServantB ServantC ObjectAdapter Ogni oggetto viene dotato di un servant che prevede un thread dalla prima attivazione e risponde solo attraverso quello Client1 Client2 Client3 Si limita il parallelismo in base al numero dei servant Capacità di Esecuzione Middleware e CORBA 51 Funzioni di ADATTATORE Gli Adattatori controllano la esecuzione delle operazioni nei server attraverso il concetto di servant USO di SERVANT Un servant è la parte di oggetto che mette a disposizione il codice da eseguire su richiesta di un cliente (entità fortemente dipendenti dal linguaggio di programmazione e dalla specifica implementazione del servitore) Il POA ha il compito di comporre la immagine dell oggetto CORBA server. Potrebbe essere presente: un unico servant anche molti diversi da fornire alle diverse richieste Un POA decide i propri servant e la politica di gestione Middleware e CORBA 52

27 RIFERIMENTI AD OGGETTI in CORBA Necessità di identificatori da passare tra ambienti diversi CORBA 1.2 non prevedeva nomi unici CORBA 2 supporto per nomi unici Object Reference come nomi non unici associati ad un servizio ObjectRef al passaggio viene convertito da un sistema di nomi in un proxy nell'ambiente del ricevente per potere essere utilizzato ObjectRef possono essere passati da un ambiente ad un altro ed essere utilizzati dovunque ma non necessariamente per lo stesso oggetto In un ambiente ricevente il riferimento potrebbe essere per un oggetto diverso con la stessa interfaccia in caso di stato sul server, problemi Middleware e CORBA 53 Middleware I middleware più usati devono prevedere risposte anche ad esigenze spicciole e a dettagli ulteriori I programmatori di CORBA si aspettano di potere: - progettare velocemente nuovi componenti - integrare vecchi componenti legacy - potere utilizzare strumenti esistenti e componenti di ausilio pronti - potere integrare le applicazioni con facility disponibili Middleware e CORBA 54

28 ARCHITETTURA CORBA Middleware e CORBA 55 COMPONENTI DI CORBA I componenti essenziali di CORBA * Object Request Broker (ORB) * Interface Definition Language (IDL) * Basic (e altri) Object Adapter (BOA) * Static Invocation Interface (SII) * Dynamic Invocation Interface (DII) * Interface Repository (IR) * Protocolli per Integrazione (GIOP) Middleware e CORBA 56

29 CORBA VERSIONI CORBA mantiene i componenti essenziali anche nella sua evoluzione ma si arricchisce di strumenti e di componenti per ovviare ai problemi man mano delineati per fornire un migliore supporto Componenti essenziali sempre gli stessi Interazione tra ambienti di linguaggi diversi Aiuti per l uso di ambienti di linguaggi diversi Strumenti per ottenere QoS in ambienti di linguaggi diversi Nuove utilità generali e per domini specifici Nuove realizzazioni ed integrazione con diversi ambienti di sviluppo esistenti CORBA 3 Middleware e CORBA 57 CORBA ARCHITETTURA Visione di insieme della architettura base di supporto al servizio Middleware e CORBA 58

30 CORBA ARCHITETTURA Visione di insieme della architettura base di supporto al servizio Middleware e CORBA 59 SISTEMI CORBA DIVERSI Definizione (dalla versione 2) di Protocolli InterORB per stabilire come fare interagire diversi sistemi CORBA protocollo di interoperabilità tra ORB General Inter-ORB Protocol (GIOP) Specifica comune della rappresentazione dei dati, del formato dei messaggi, dell interazione con messaggi di trasporto (assunzioni semantiche: reliable, connection, ) per Internet su TCP/IP Internet Inter-ORB Protocol (IIOP) Middleware e CORBA 60

31 CORBA IDL Linguaggio per definire le interfacce in CORBA indipendente dai singoli linguaggi concreti di programmazione Middleware e CORBA 61 CORBA IDL CORBA è un ambiente in cui usiamo riferimenti remoti e non muoviamo oggetti (oggetti fissi) vista la eterogeneità dei singoli ambienti concreti di deployment I riferimenti remoti sono il modo di richiedere operazioni ad altri componenti con interfaccia CORBA Le interfacce prevedono: attributi, operazioni, eccezioni (attributi acceduti attraverso operazioni di get e di set) (operazioni con argomenti di in o/e out) Le interfacce in ereditarietà multipla Le interfacce sono anche racchiuse in moduli (per aggregazioni logiche) Middleware e CORBA 62

32 CORBA IDL module ContoCorrente { struct movimento { string data; float importo;}; exception RossoException {string message;}; typedef sequence <movimento> lista_op; interface Conto { attribute string cognome; float saldo (in string cc); lista_op estratto (in string cc); void prelievo (in string cc, in float importo, out float saldo) raises RossoException; }; }; Middleware e CORBA 63 Tipi in CORBA CORBA IDL Object Reference (oggetti) vs. Value (copia di valori) Exceptions Value Basic values short, long, ushort, ulong, float, double, char, string, boolean, octet, enum, Any Constructed values Struct, Sequence, Union, Array Any come tipo generico valido a tempo di esecuzione Object by value (CORBA 3) Oggetti che non possono essere acceduti da remoto e possono passare da un ambiente ad un altro solo per copia superando le eterogeneità dei diversi ambienti (nessun IOR) Middleware e CORBA 64

33 Tipi in CORBA IDL Object Reference Type Tipi Costruiti Eccezioni CORBA IDL Struct Sequence Union Array I tipi di CORBA IDL sono poi traslati nei tipi dei diversi linguaggi di programmazione ottenuti per i diversi language mapping Valori base Il tipo generico ANY permette di contenere qualunque tipo di dato e si comporta come il tipo Object dei linguaggi di programmazione ad oggetti Tipo generico ANY Short Long Ushort Ulong float double char string boolean octet enum any Middleware e CORBA 65 CORBA IDL Si usano strumenti per derivare dal CORBA IDL i diversi componenti necessari per la esecuzione stub e skeleton + file helper di aiuto Middleware e CORBA 66

34 CORBA- IDL module Stock {exception Invalid_Stock {}; exception Invalid_Index {}; const length = 100; interface Quoter { attribute float quote; readonly attribute float quotation; void one_way set_quote(in string stock_name, in long value); long get_quote(in string stock_name) raises (Invalid_Stock); }; interface SpecialQuoter: Quoter { attribute float quotehistory [length]; readonly int index [length]; long get_next (in string stock_name) raises (Invalid_Index); long get_first(in string stock_name) raises (Invalid_Index); }; } Middleware e CORBA 67 Per ogni attributo si mettono a disposizione automaticamente funzioni di accesso adatte alle operazioni consentite (_get per letture e _set per scritture) attribute float quote; float _get_quote (); void _set_quote (in float q); readonly attribute ind index; float _get_index (); Per ogni eccezione, lo stato (completion_status) fornisce informazioni semantiche sul completamento COMPLETED_YES, COMPLETED_NO, COMPLETED_MAYBE CORBA- IDL Middleware e CORBA 68

35 PROGETTO PROGRAMMI CORBA Si devono specificare le interfacce comuni a server e clienti Dopo avere generato gli stub e skeleton Si implementano le classi server Il server deve registrarsi Si implementano le classi client Si va alla esecuzione Necessità di riferimenti remoti del cliente per ritrovare il server, i componenti,, e in generale la intera infrastruttura di supporto Middleware e CORBA 69 COMPONENTI DI CORBA Middleware e CORBA 70

36 Object Reference in CORBA Gli Object Reference permettono di ritrovare una istanza di un servizio remoto (uno stub): sono opachi e non sono manipolabili dai clienti ma solo dall ORB (eventualmente integrati con la gestione della persistenza) Gli Object Reference sono riferimenti ad istanze di Object Interface Operazioni di Object Interface sono molte per consentire di lavorare in modo trasparente e visibile get_implementation, get_interface, is_nil, non_existent, is_a, is_equivalent, hash, duplicate, release, create_request, get_domain_manager, get_policy, set_policy_overrides, Middleware e CORBA 71 ORB INTERFACE in CORBA ORB si può intendere come l insieme di classi che permettono un buon supporto ad oggetti remoti Funzioni di conversioni varie funzioni helper per lavorare e trasformare gli Object Interface Interface ORB { string object_to_string (in Object obj); Object string_to_object (in string str); } possiamo così passare da una forma all altra anche tra ambienti diversi Anche funzioni per inizializzare i vari OA, per ritrovare servizi necessari, funzioni di base, ecc. ecc. Middleware e CORBA 72

37 ORB Funzioni varie ORB INTERFACE in CORBA ORB Initialize per il boot ORB ORB_init(inout arg_list arguments, in ORBid ORB_identifier) per il collegamento iniziale all ORB da parte dei clienti Anche object_to_string e string_to_object anche funzioni per ritrovare il contesto di default e interrogare IR typedef string ObjectID; typedef sequence <ObjectID> ObjectIDList; ObjectIDList list_initial_services (); Object resolve_initial_references (in ObjectID id); Middleware e CORBA 73 RIFERIMENTI AD OGGETTI in CORBA Necessità di identificatori da passare tra ambienti diversi CORBA 2 supporto sia per nomi unici e non unici Object Reference come nomi non unici associati ad un servizio ObjectRef al passaggio viene convertito da un sistema di nomi in un proxy nell'ambiente del ricevente per potere essere utilizzato ObjectRef possono essere passati da un ambiente ad un altro ed essere utilizzati dovunque ma non necessariamente per lo stesso oggetto (all interno di ORB diversi anche forme diverse) Possono contenere informazioni di: indirizzo nome del POA di creazione object ID Middleware e CORBA 74

38 NOMI UNICI in CORBA Necessità di identificatori unici tra ambienti diversi Interoperable Object Reference come nomi unici associati ad un servizio (IOR) che possono essere portati tra ORB diversi (passando anche attraverso stringhe) In genere, prima di passare da un ORB ad un altro IOR Cliente Object Reference IDL:MyObject:1.0 N_porta: ip_address OA1, Obj_2 Op() [OA1, Obj_2] Risposta Servitore Object Adapter: OA1 Obj_1 Obj_2 Obj_3 Middleware e CORBA 75 Interoperable Object Reference Accordo tra le rappresentazioni dei diversi ORB per i diversi oggetti che esistono al di fuori dell ORB Interoperable Object Reference o IOR IOR come ProfileID (identificatore) e tagged Profile (per determinare completamente) Middleware e CORBA 76

39 IOR in CORBA Inserimento in un Repository (appena depositato la prima volta) Repository Identifier Tagged Profile informazioni complete per la ricerca dell oggetto IIOP, nome host, porta, chiave identificativa, info. aggiuntive Si usano queste informazioni per decidere cosa passare al cliente che richiede una operazione (poi gli viene fornito il proxy locale per l oggetto stesso) Legame diretto (direct binding) se IOR riferisce direttamente l oggetto relativo Legame indiretto (indirect binding) se IOR riferisce al repository e solo indirettamente attraverso questo all oggetto finale Middleware e CORBA 77 IOR in CORBA Legame diretto e Legame indiretto (direct e indirect binding) Cliente Interoperable Object Reference (5) Op() [OA1, Obj_2] IDL:MyObject:1.0 n _porta: ip _address OA1, Obj_2 Risposta (7) (4) Location-forward ( N_porta_1: IP_Address_1) (2) Vbj /applicazioni /server: (1) Comando per attivare Op() [OA_1, Obj_2] il servizio Implementation Repository localizzato a n _porta: ip _address OA_1 Vbj \applicazioni\server Servitore N_porta_1: IP_Address_1 N_porta_1: IP_Address_1 Object Adapter: OA1 Obj_1 Obj_2 Obj_3 (3) Restituisce: N_porta_1: IP_Address_1 OA_2 Vbj \pub\gestore N_porta_2: IP_Address_2 OA_3 Implementation Repository Middleware e CORBA 78

40 OBJECT ADAPTER in CORBA Object Adapter come agenti intermedi per consentire di superare i problemi della eterogeneità dei diversi ambienti BOA (Basic Object Adapter) come la entità di base Permette la attivazione dei server con politiche semplici Shared server Unshared server Per Method server Persistent server un unico thread per tutti gli oggetti un processo per ogni oggetto un processo per ogni invocazione un processo unico fatto partire alla inizializzazione Middleware e CORBA 79 PORTABLE OBJECT ADAPTER - POA POA come agente portabile interoperabile che permette di passare da un object reference al codice concreto che deve servire la richiesta stessa Un POA può gestire molti oggetti diversi e seleziona su quali dirigere le operazioni In ambienti diversi, il POA è diverso (classi, variabili, metodi, attività) ma deve potere realizzare le politiche di base necessarie alla varietà delle interazioni possibili In un ambiente specifico, in genere esiste una classe base da cui derivano tutti i POA e che contiene i meccanismi per la gestione della richiesta e dei servant Il POA non eredita le politiche definite caso per caso Middleware e CORBA 80

41 PORTABLE OBJECT ADAPTER - POA POA come agente portabile per la interoperabilità Eredita da altri POA (di default) senza ereditare le politiche che devono essere espresse ad-hoc Politiche anche diverse e specializzate Middleware e CORBA 81 Funzioni di ADATTATORE Gli Adattatori POA hanno un metodo visibile ai clienti ObjectID activate_object (in Servant p) che restituisce un identificatore di oggetto CORBA e può ricevere in ingresso un puntatore ad un servant Il metodo permette anche la gestione della scelta esplicita tra servant nella Active Object Map ObjectID permettono la scelta dei servant nel POA Middleware e CORBA 82

42 PORTABLE OBJECT ADAPTER POA viene gestito da un POA Manager che esprime le politiche (come mappare servant e object reference) e le realizza Middleware e CORBA 83 PORTABLE OBJECT ADAPTER POA Manager capace di fornire operazioni per consentire politiche diverse. Il POA Manager permette di: attivare un POA (per fare partire il lavoro) disattivare un POA (per chiudere il lavoro dei POA) bloccare le richieste ai POA (il lavoro viene bloccato e non si fa partire nessuna operazione) scartare le richieste per i POA (tutte le richieste in arrivo e accodate sono scartate: nessuna operazione) Middleware e CORBA 84

43 OBJECT ADAPTER in CORBA POA come agente portabile per la gestione degli oggetti e dei servant RESPONSABILITÀ di Creazione object reference Identificazione degli ObjectID Gestire i servant relativi Oggetti CORBA transienti che non sopravvivono alla applicazione che li ha generati Oggetti CORBA persistenti che sopravvivono alla applicazione che li ha generati e rimangono disponibili anche per altre successive applicazioni Middleware e CORBA 85 OBJECT ADAPTER in CORBA POA come agente portabile per la interoperabilità le politiche derivano da proprietà specificate ad-hoc: Thread (ORB_CTRL_MODEL, SINGLE_THREAD_MODEL) Lifespan (TRANSIENT, PERSISTENT) Object ID Uniqueness (UNIQUE_ID, MULTIPLE_ID) ID Assignment (USER_ID, SYSTEM_ID) Servant Retention (RETAIN, NON_RETAIN) Requests (USE_ACTIVE_OBJECT_MAP_ONLY, USE_DEFAULT_SERVANT, USE_SERVANT_MANAGER) Implicit Activation (IMPLICIT_ACTIVATION, NO_IMPLICIT_ACTIVATION) Middleware e CORBA 86

44 POLITICHE PER I POA POA può consentire politiche molto differenziate per la gestione degli oggetti servant Politiche a default POA: Explicit Object Activation Un servant specifico è collegato ad un ObjectID con molto controllo della esecuzione Single Servant (per tutti gli oggetti) Un solo servant per ogni richiesta (anche oggetti di tipo diverso) On-Demand activation (per un singolo metodo) senza stato On-Demand activation (per durata indefinita) il servant si attiva su richiesta e si mantiene per ogni richiesta successiva Si possono anche combinare Middleware e CORBA 87 INTERFACE REPOSITORY in CORBA Interface Repository si occupa di registrare tutte le interfacce e di gestirne la memorizzazione e la ricerca Distingue tra contenitore e contenuti Middleware e CORBA 88

45 INTERFACE REPOSITORY in CORBA Interface Repository ad accesso direttamente o attraverso utilità proprietarie Ogni entità viene anche etichettata da un RepositoryID Si raccomandano formati diversi IDL IDL:/Vai/Servizi/Interfaccia:1.0 RMI hashed RMI: nome /hashcode DCE format DCE: UUID Local format LOCAL: libero Si fanno operazioni di accesso Contained lookup_id (in RepositoryID searchid); InterfaceDef get_interface(); Middleware e CORBA 89 INTERFACE REPOSITORY in CORBA Ad ogni interfaccia definita e compilata Si generano delle trascrizioni delle informazioni nell IR in base ai tipi che possono essere riconosciuti Middleware e CORBA 90

CORBA ( Common Object Request Broker Architecture ) Le specifiche più conosciute sono UML e CORBA

CORBA ( Common Object Request Broker Architecture ) Le specifiche più conosciute sono UML e CORBA CORBA ( Common Object Request Broker Architecture ) consiste in un insieme di specifiche promosse e curate da OMG (Object Management Group). L OMG è un consorzio internazionale no-profit di industrie nel

Dettagli

Corso di Reti di Calcolatori LS

Corso di Reti di Calcolatori LS Università degli Studi di Bologna Facoltà di Ingegneria Corso di Reti di Calcolatori LS CORBA - Implementazione Naming Service e Interface Repository Luca Foschini Anno accademico 2008/2009 Agenda CORBA

Dettagli

Corso di Reti di Calcolatori LS

Corso di Reti di Calcolatori LS Università degli Studi di Bologna Facoltà di Ingegneria Corso di Reti di Calcolatori LS MIDDLEWARE VARI Antonio Corradi Anno accademico 2004/2005 Middleware 1 MIDDLEWARE Definizione di MIDDLEWARE Insieme

Dettagli

Distributed Object Computing

Distributed Object Computing Evoluzione Architetturale Distributed omputing entralizzata Monolitica anni 60-70 Reti locali di P anni 80 Reti lient Server anni 80-90 Internet The network is the computer Paolo Falcarin Sistemi Informativi

Dettagli

8. Sistemi Distribuiti e Middleware

8. Sistemi Distribuiti e Middleware 8. Sistemi Distribuiti e Middleware Andrea Polini Ingegneria del Software Corso di Laurea in Informatica (Ingegneria del Software) 8. Sistemi distribuiti e Middleware 1 / 32 Sommario 1 Sistemi distribuiti

Dettagli

CORBA. CORBA facilita lo sviluppo di sistemi distribuiti fornendo

CORBA. CORBA facilita lo sviluppo di sistemi distribuiti fornendo CORBA CORBA facilita lo sviluppo di sistemi distribuiti fornendo Una infrastruttura per far comunicare oggetti in un sistema distribuito Un set di servizi utili Un supporto che permette ad applicazioni

Dettagli

CORBA & DCOM. Gianpaolo Cugola cugola@elet.polimi.it http://www.elet.polimi.it/~cugola. La Object Management Architecture

CORBA & DCOM. Gianpaolo Cugola cugola@elet.polimi.it http://www.elet.polimi.it/~cugola. La Object Management Architecture CORBA & DCOM Gianpaolo Cugola cugola@elet.polimi.it http://www.elet.polimi.it/~cugola Sommario La Object Management Architecture CORBA La programmazione di applicazioni CORBA in Java CORBA vs. RMI DCOM

Dettagli

Progetto di Applicazioni Software

Progetto di Applicazioni Software Progetto di Applicazioni Software Antonella Poggi Dipartimento di Informatica e Sistemistica Antonio Ruberti SAPIENZA Università di Roma Anno Accademico 2008/2009 Questi lucidi sono stati prodotti sulla

Dettagli

Progetto di Applicazioni Software

Progetto di Applicazioni Software Progetto di Applicazioni Software Antonella Poggi Dipartimento di Informatica e Sistemistica Antonio Ruberti SAPIENZA Università di Roma Anno Accademico 2010/2011 Questi lucidi sono stati prodotti sulla

Dettagli

Programmazione di sistemi distribuiti

Programmazione di sistemi distribuiti Programmazione di sistemi distribuiti I Sistemi Distribuiti, per loro natura, prevedono che computazioni differenti possano essere eseguite su VM differenti, possibilmente su host differenti, comunicanti

Dettagli

ALLEGATO C STANDARD TECNICI DELLA BORSA CONTINUA NAZIONALE DEL LAVORO

ALLEGATO C STANDARD TECNICI DELLA BORSA CONTINUA NAZIONALE DEL LAVORO ALLEGATO C STANDARD TECNICI DELLA BORSA CONTINUA NAZIONALE DEL LAVORO Standard tecnici Gli standard tecnici di riferimento adottati sono conformi alle specifiche e alle raccomandazioni emanate dai principali

Dettagli

Java Remote Method Invocation

Java Remote Method Invocation Java Remote Method Invocation Programmazione in Rete e Laboratorio Comunicazione distribuita Port1 Java VM1 Java VM2 Port 2 Matteo Baldoni Dipartimento di Informatica Universita` degli Studi di Torino

Dettagli

SISTEMI OPERATIVI DISTRIBUITI

SISTEMI OPERATIVI DISTRIBUITI SISTEMI OPERATIVI DISTRIBUITI E FILE SYSTEM DISTRIBUITI 12.1 Sistemi Distribuiti Sistemi operativi di rete Sistemi operativi distribuiti Robustezza File system distribuiti Naming e Trasparenza Caching

Dettagli

CdL MAGISTRALE in INFORMATICA

CdL MAGISTRALE in INFORMATICA 05/11/14 CdL MAGISTRALE in INFORMATICA A.A. 2014-2015 corso di SISTEMI DISTRIBUITI 7. I processi : il naming Prof. S.Pizzutilo Il naming dei processi Nome = stringa di bit o di caratteri utilizzata per

Dettagli

Naming nei Sistemi Distribuiti

Naming nei Sistemi Distribuiti Naming nei Sistemi Distribuiti Naming (1) La risoluzione dei nomi permette ad un processo di accedere ad una entità in un sistema distribuito. Un sistema di naming è necessario per avere un modello comune

Dettagli

Naming nei Sistemi Distribuiti

Naming nei Sistemi Distribuiti Naming nei Sistemi Distribuiti Naming (1) La risoluzione dei nomi permette ad un processo di accedere ad una entità in un sistema distribuito. Un sistema di naming è necessario per avere un modello comune

Dettagli

Architetture software

Architetture software Sistemi Distribuiti Architetture software 1 Sistemi distribuiti: Architetture software Il software di gestione di un sistema distribuito ha funzionalità analoghe ad un sistema operativo Gestione delle

Dettagli

Enterprise @pplication Integration Software S.r.l.

Enterprise @pplication Integration Software S.r.l. SAP rel.1.0 : SAP State: Final Date: 03-27-200 Enterprise @pplication Integration Software S.r.l. Sede legale: Via Cola di Rienzo 212-00192 Rome - Italy Tel. +39.06.6864226 Sede operativa: viale Regina

Dettagli

Siti web centrati sui dati (Data-centric web applications)

Siti web centrati sui dati (Data-centric web applications) Siti web centrati sui dati (Data-centric web applications) 1 A L B E R T O B E L U S S I A N N O A C C A D E M I C O 2 0 1 2 / 2 0 1 3 WEB La tecnologia del World Wide Web (WWW) costituisce attualmente

Dettagli

INTRODUZIONE. Data Base Management Systems evoluzione tecniche gestione dati

INTRODUZIONE. Data Base Management Systems evoluzione tecniche gestione dati INTRODUZIONE Accesso ai dati tramite DBMS Livelli di astrazione Modello dei dati: schema / istanza / metadati Alcuni modelli dei dati Linguaggi per DBMS Architettura di base di un DBMS cesarini - BDSI

Dettagli

Ministero del Lavoro e delle Politiche Sociali

Ministero del Lavoro e delle Politiche Sociali Ministero del Lavoro e delle Politiche Sociali Prospetto Informativo on-line Standard tecnici del sistema informativo per l invio telematico del Prospetto Informativo Documento: UNIPI.StandardTecnici Revisione

Dettagli

Architetture software

Architetture software Corso di Laurea Magistrale in Ingegneria Informatica Corso di Ingegneria del A. A. 2013-2014 Architettura software 1 Architetture software Sommario Definizioni 2 Architettura Definizione. L architettura

Dettagli

Sistemi Operativi STRUTTURA DEI SISTEMI OPERATIVI 3.1. Sistemi Operativi. D. Talia - UNICAL

Sistemi Operativi STRUTTURA DEI SISTEMI OPERATIVI 3.1. Sistemi Operativi. D. Talia - UNICAL STRUTTURA DEI SISTEMI OPERATIVI 3.1 Struttura dei Componenti Servizi di un sistema operativo System Call Programmi di sistema Struttura del sistema operativo Macchine virtuali Progettazione e Realizzazione

Dettagli

Sistemi Operativi (modulo di Informatica II)

Sistemi Operativi (modulo di Informatica II) Sistemi Operativi (modulo di Informatica II) La comunicazione tra processi Patrizia Scandurra Università degli Studi di Bergamo a.a. 2008-09 Sommario Processi cooperanti La comunicazione tra processi Necessità

Dettagli

Un approccio innovativo per il delivery di servizi in infrastrutture di nomadic computing

Un approccio innovativo per il delivery di servizi in infrastrutture di nomadic computing Un approccio innovativo per il delivery di servizi in infrastrutture di nomadic computing Relatore Prof. Ing. Stefano Russo Correlatore Ing. Domenico Cotroneo Candidato Armando Migliaccio matr. 41/2784

Dettagli

RMI Remote Method Invocation

RMI Remote Method Invocation RMI Remote Method Invocation [Pagina intenzionalmente vuota] (1 12 2004) slide 4:1/18 (p.106) Un applicazione RMI è un applicazione distribuita ad oggetti. Applicazione RMI tipica, strutturata in: server:

Dettagli

Elementi di Informatica e Programmazione

Elementi di Informatica e Programmazione Elementi di Informatica e Programmazione Le Reti di Calcolatori (parte 2) Corsi di Laurea in: Ingegneria Civile Ingegneria per l Ambiente e il Territorio Università degli Studi di Brescia Docente: Daniela

Dettagli

Applicazioni web centrati sui dati (Data-centric web applications)

Applicazioni web centrati sui dati (Data-centric web applications) Applicazioni web centrati sui dati (Data-centric web applications) 1 ALBERTO BELUSSI ANNO ACCADEMICO 2009/2010 WEB La tecnologia del World Wide Web (WWW) costituisce attualmente lo strumento di riferimento

Dettagli

Candidato: Luca Russo Docente: Prof. Raffaele Montella. 27 Marzo 2013

Candidato: Luca Russo Docente: Prof. Raffaele Montella. 27 Marzo 2013 e di e di Candidato: Luca Russo Docente: Corso di laurea in Informatica Applicata Facoltá di Scienze e Tecnologie Programmazione su Reti 27 Marzo 2013 Traccia d esame Sviluppare multitier con disaccoppiamento

Dettagli

Internet, Security & Information Technologies

Internet, Security & Information Technologies Internet, Security & Information Technologies I sistemi distribuiti: lo standard CORBA Sommario Il Middleware Introduzione ai sistemi distribuiti e al concetto di middleware CORBA: concetti generali Introduzione

Dettagli

Framework. Impianti Informatici. Web application - tecnologie

Framework. Impianti Informatici. Web application - tecnologie Framework Web application - tecnologie Web Application: tecnologie 2 Java-based (J2EE) Sviluppata inizialmente da Sun Cross-platform e open source Gestire direttamente le funzionalità dell applicazione

Dettagli

Comunicazione tra Processi

Comunicazione tra Processi Comunicazione tra Processi Comunicazioni in un Sistema Distribuito Un sistema software distribuito è realizzato tramite un insieme di processi che comunicano, si sincronizzano, cooperano. Il meccanismo

Dettagli

Comunicazione tra Processi

Comunicazione tra Processi Comunicazione tra Processi Comunicazioni in un Sistema Distribuito Un sistema software distribuito è realizzato tramite un insieme di processi che comunicano, si sincronizzano, cooperano. Il meccanismo

Dettagli

Sistemi Informativi Distribuiti

Sistemi Informativi Distribuiti Corso di Laurea Magistrale in Ingegneria Gestionale Corso di Sistemi Informativi Modulo II A. A. 2013-2014 SISTEMI INFORMATIVI MODULO II Sistemi Informativi Distribuiti 1 Sistemi informativi distribuiti

Dettagli

Concetti base. Impianti Informatici. Web application

Concetti base. Impianti Informatici. Web application Concetti base Web application La diffusione del World Wide Web 2 Supporto ai ricercatori Organizzazione documentazione Condivisione informazioni Scambio di informazioni di qualsiasi natura Chat Forum Intranet

Dettagli

Inizializzazione degli Host. BOOTP e DHCP

Inizializzazione degli Host. BOOTP e DHCP BOOTP e DHCP a.a. 2002/03 Prof. Vincenzo Auletta auletta@dia.unisa.it http://www.dia.unisa.it/~auletta/ Università degli studi di Salerno Laurea e Diploma in Informatica 1 Inizializzazione degli Host Un

Dettagli

BANCA VIRTUALE/1 tecnologie dell informazione della comunicazione

BANCA VIRTUALE/1 tecnologie dell informazione della comunicazione BANCA VIRTUALE/1 Il termine indica un entità finanziaria che vende servizi finanziari alla clientela tramite le tecnologie dell informazione e della comunicazione, senza ricorrere al personale di filiale

Dettagli

27/03/2013. Contenuti

27/03/2013. Contenuti Corso Sistemi Distribuiti 6 cfu Docente: Prof. Marcello Castellano Contenuti Virtualizzazione - 3 Macchina virtuale - 4 Architetture delle macchine virtuali - 6 Tipi di virtualizzazione - 7 Monitor della

Dettagli

Il Sistema Operativo. C. Marrocco. Università degli Studi di Cassino

Il Sistema Operativo. C. Marrocco. Università degli Studi di Cassino Il Sistema Operativo Il Sistema Operativo è uno strato software che: opera direttamente sull hardware; isola dai dettagli dell architettura hardware; fornisce un insieme di funzionalità di alto livello.

Dettagli

Protocolli e architetture per WIS

Protocolli e architetture per WIS Protocolli e architetture per WIS Web Information Systems (WIS) Un Web Information System (WIS) usa le tecnologie Web per permettere la fruizione di informazioni e servizi Le architetture moderne dei WIS

Dettagli

Programmazione CORBA in Java

Programmazione CORBA in Java Programmazione CORBA in Java Trasparenze dalle lezioni del corso di Reti di Calcolatori A.A. 2002/2003 Prof. Roberto Baldoni - Ing. Antonino Virgillito CORBA Specifica standard di middleware RPC ad oggetti

Dettagli

Presentazione di Cedac Software

Presentazione di Cedac Software Agenda Presentazione di Cedac Software SOA ed ESB Analisi di un caso studio Esempi Q&A Presentazione di Cedac Software 1 2 Presentazione di Cedac Software S.r.l. Divisione Software Azienda nata nel 1994

Dettagli

Web Service Architecture

Web Service Architecture Giuseppe Della Penna Università degli Studi di L Aquila dellapenna@di.univaq.it http://dellapenna.univaq.it Engineering IgTechnology Info92 Maggioli Informatica Micron Technology Neta Nous Informatica

Dettagli

Comunicazione fra oggetti distribuiti

Comunicazione fra oggetti distribuiti Comunicazione fra oggetti distribuiti RMI RPC invocazione di metodo remoto - gli oggetti remoti ricevono le RMI interfaccia remota meccanismo per la comunicazione cliente servente come primitiva di un

Dettagli

Introduzione alle applicazioni di rete

Introduzione alle applicazioni di rete Introduzione alle applicazioni di rete Definizioni base Modelli client-server e peer-to-peer Socket API Scelta del tipo di servizio Indirizzamento dei processi Identificazione di un servizio Concorrenza

Dettagli

Programmazione II. Lezione 4. Daniele Sgandurra 30/09/2011. daniele.sgandurra@iit.cnr.it

Programmazione II. Lezione 4. Daniele Sgandurra 30/09/2011. daniele.sgandurra@iit.cnr.it Programmazione II Lezione 4 Daniele Sgandurra daniele.sgandurra@iit.cnr.it 30/09/2011 1/46 Programmazione II Lezione 4 30/09/2011 Sommario 1 Esercitazione 2 Panoramica della Programmazione Ad Oggetti 3

Dettagli

Chiamate a Procedure Remote

Chiamate a Procedure Remote FACOLTA DI SCIENZE MATEMATICHE, FISICHE E NATURALI Corso di Laurea Magistrale in Informatica Corso di Sistemi Distribuiti Anno Accademico 2012/2013 Relazione sullo sviluppo di Chiamate a Procedure Remote

Dettagli

Architetture a oggetti distribuiti

Architetture a oggetti distribuiti Luca Cabibbo Architetture Software Architetture a oggetti distribuiti Dispensa ASW 420 ottobre 2014 Tutti sanno che una certa cosa è impossibile da realizzare, finché arriva uno sprovveduto che non lo

Dettagli

Sistemi Distribuiti Introduzione al corso

Sistemi Distribuiti Introduzione al corso Altri testi di consultazione Sistemi Distribuiti Introduzione al corso Testo di riferimento G.Coulouris, J.Dollimore and T.Kindberg Distributed Systems: Concepts and Design IV Ed., Addison-Wesley 2005

Dettagli

Il.NET Framework. By Dario Maggiari. L architettura del.net Framework è riassunta, nel complesso, nella figura seguente:

Il.NET Framework. By Dario Maggiari. L architettura del.net Framework è riassunta, nel complesso, nella figura seguente: Il.NET Framework By Dario Maggiari L architettura del.net Framework è riassunta, nel complesso, nella figura seguente: Il cuore del.net Framework è costituito dal CLR (Common Language Runtime) che, secondo

Dettagli

Elementi di Informatica e Programmazione

Elementi di Informatica e Programmazione Elementi di Informatica e Programmazione Le Reti di Calcolatori (parte 2) Corsi di Laurea in: Ingegneria Civile Ingegneria per l Ambiente e il Territorio Università degli Studi di Brescia Docente: Daniela

Dettagli

La Roadmap dello sviluppo per System i5: dalle Applicazioni Legacy alla SOA

La Roadmap dello sviluppo per System i5: dalle Applicazioni Legacy alla SOA IBM System i5 La Roadmap dello sviluppo per System i5: dalle Applicazioni Legacy alla SOA Massimo Marasco System i Technical Sales Support massimo_marasco@it.ibm.com Oriented Architecture (SOA) Servizio

Dettagli

Corso Sviluppatore servizi per il Web (WCF) Lezione 01

Corso Sviluppatore servizi per il Web (WCF) Lezione 01 01 Introduzione Introduzione alla tecnologia WCF Premessa Il corso su WCF di cui state leggendo la prima lezione, vi guiderà alla scoperta di questa nuova tecnologia introdotta da Microsoft per venire

Dettagli

JDBC versione base. Le classi/interfacce principali di JDBC

JDBC versione base. Le classi/interfacce principali di JDBC JDBC versione base Java Database Connectivity è il package Java per l accesso a database relazionali il package contiene interfacce e classi astratte uno dei pregi è la completa indipendenza del codice

Dettagli

Componenti Web: client-side e server-side

Componenti Web: client-side e server-side Componenti Web: client-side e server-side side Attività di applicazioni web Applicazioni web: un insieme di componenti che interagiscono attraverso una rete (geografica) Sono applicazioni distribuite logicamente

Dettagli

Componenti di una applicazione. Un programma applicativo è strutturato come un insieme organizzato di tre componenti funzionali:

Componenti di una applicazione. Un programma applicativo è strutturato come un insieme organizzato di tre componenti funzionali: Componenti di una applicazione Un programma applicativo è strutturato come un insieme organizzato di tre componenti funzionali: Un sottosistema di interfaccia con l utente (IU, user interface o anche presentation

Dettagli

Socket & RMI Ingegneria del Software - San Pietro

Socket & RMI Ingegneria del Software - San Pietro Socket & RMI Ingegneria del Software - San Pietro Socket È possibile trattare la comunicazione di rete allo stesso modo con cui è possibile trattare la lettura da file. La classe Socket rappresenta la

Dettagli

DATABASE IN RETE E PROGRAMMAZIONE LATO SERVER

DATABASE IN RETE E PROGRAMMAZIONE LATO SERVER DATABASE IN RETE E PROGRAMMAZIONE LATO SERVER L architettura CLIENT SERVER è l architettura standard dei sistemi di rete, dove i computer detti SERVER forniscono servizi, e computer detti CLIENT, richiedono

Dettagli

Reti di Telecomunicazione Lezione 6

Reti di Telecomunicazione Lezione 6 Reti di Telecomunicazione Lezione 6 Marco Benini Corso di Laurea in Informatica marco.benini@uninsubria.it Lo strato di applicazione protocolli Programma della lezione Applicazioni di rete client - server

Dettagli

Sistemi Operativi. Lez. 13: primitive per la concorrenza monitor e messaggi

Sistemi Operativi. Lez. 13: primitive per la concorrenza monitor e messaggi Sistemi Operativi Lez. 13: primitive per la concorrenza monitor e messaggi Osservazioni I semafori sono strumenti particolarmente potenti poiché consentono di risolvere ogni problema di sincronizzazione

Dettagli

Capitolo 5: I thread

Capitolo 5: I thread Capitolo 5: I thread Generalità. Modelli multithread. Problematiche relative ai thread. Pthread. 5.1 I thread Il thread è un flusso di controllo relativo ad un dato processo. Molti sistemi operativi moderni

Dettagli

Seminario di Sistemi Distribuiti: RPC su SOAP

Seminario di Sistemi Distribuiti: RPC su SOAP Corso di Sistemi Distribuiti Prof. S. Balsamo Seminario di Sistemi Distribuiti: RPC su SOAP [ 777775] 1 INTRODUZIONE 3 2 RPC 3 3 SOAP (SIMPLE OBJECT ACCESS PROTOCOL) 3 4 UTILIZZO DI SOAP COME PROTOCOLLO

Dettagli

Sommario. G. Piscitelli

Sommario. G. Piscitelli Sommario Interprocess Communication Processi (e thread) cooperanti Il paradigma produttore-consumatore Shared Memory e Inter Process Communication (IPC) facility Proprietà caratteristiche della comunicazione

Dettagli

Problema del naming. Modello di Naming

Problema del naming. Modello di Naming Sistemi Distribuiti Problema del naming 1 Modello di Naming Conoscenza reciproca delle entità / servizi In una relazione cliente/servitore il cliente deve avere un riferimento al servitore Problema della

Dettagli

Introduzione ai Web Services Alberto Polzonetti

Introduzione ai Web Services Alberto Polzonetti PROGRAMMAZIONE di RETE A.A. 2003-2004 Corso di laurea in INFORMATICA Introduzione ai Web Services alberto.polzonetti@unicam.it Introduzione al problema della comunicazione fra applicazioni 2 1 Il Problema

Dettagli

UNIVERSITA DI FIRENZE Facoltà di Ingegneria. Persistenza Applicazioni Enterprise Uso dei modelli

UNIVERSITA DI FIRENZE Facoltà di Ingegneria. Persistenza Applicazioni Enterprise Uso dei modelli UNIVERSITA DI FIRENZE Facoltà di Ingegneria Persistenza Applicazioni Enterprise Uso dei modelli 1 IL problema della persistenza APPLICAZIONE (programmi) (oggetti) DATI PERSISTENTI (file, record) (basi

Dettagli

Integrazione di Sistemi Informativi Sanitari attraverso l uso di Middleware Web Services

Integrazione di Sistemi Informativi Sanitari attraverso l uso di Middleware Web Services Consiglio Nazionale delle Ricerche Istituto di Calcolo e Reti ad Alte Prestazioni Integrazione di Sistemi Informativi Sanitari attraverso l uso di Middleware Web Services I. Marra M. Ciampi RT-ICAR-NA-06-04

Dettagli

Progettazione: Tecnologie e ambienti di sviluppo

Progettazione: Tecnologie e ambienti di sviluppo Contratto per l acquisizione di servizi di Assistenza specialistica per la gestione e l evoluzione del patrimonio software della Regione Basilicata. Repertorio n. 11016 del 25/09/2009 Progettazione: Tecnologie

Dettagli

BPEL: Business Process Execution Language

BPEL: Business Process Execution Language Ingegneria dei processi aziendali BPEL: Business Process Execution Language Ghilardi Dario 753708 Manenti Andrea 755454 Docente: Prof. Ernesto Damiani BPEL - definizione Business Process Execution Language

Dettagli

Sistemi Distribuiti. Anno Accademico 2005-06 Prof. Flavio De Paoli. Il modello ad oggetti

Sistemi Distribuiti. Anno Accademico 2005-06 Prof. Flavio De Paoli. Il modello ad oggetti Sistemi Distribuiti Anno Accademico 2005-06 Prof. Flavio De Paoli 1 Il modello ad oggetti 2 Distributed Objects 2-16 Common organization of a remote object with client-side proxy. 3 Caratteristiche Oggetti

Dettagli

12 - Introduzione alla Programmazione Orientata agli Oggetti (Object Oriented Programming OOP)

12 - Introduzione alla Programmazione Orientata agli Oggetti (Object Oriented Programming OOP) 12 - Introduzione alla Programmazione Orientata agli Oggetti (Object Oriented Programming OOP) Programmazione e analisi di dati Modulo A: Programmazione in Java Paolo Milazzo Dipartimento di Informatica,

Dettagli

DBMS ed Applicazioni Motivazioni

DBMS ed Applicazioni Motivazioni DBMS ed Applicazioni Motivazioni Sin ora abbiamo visto SQL come linguaggio per interrogare DBMS da interfaccia interattiva Nella pratica, un efficace sfruttamento delle potenzialità dei DBMS deriva dalla

Dettagli

Introduzione all elaborazione di database nel Web

Introduzione all elaborazione di database nel Web Introduzione all elaborazione di database nel Web Prof.ssa M. Cesa 1 Concetti base del Web Il Web è formato da computer nella rete Internet connessi fra loro in una modalità particolare che consente un

Dettagli

Applicazioni distribuite e sistemi ad oggetti distribuiti. RPC RMI - Web Services 1

Applicazioni distribuite e sistemi ad oggetti distribuiti. RPC RMI - Web Services 1 Applicazioni distribuite e sistemi ad oggetti distribuiti RPC RMI - Web Services 1 Complessità delle applicazioni distribuite La scrittura di applicazioni distribuite basate sull utilizzo di protocolli

Dettagli

Broker. [POSA1] Pattern-Oriented Software Architecture, 1996

Broker. [POSA1] Pattern-Oriented Software Architecture, 1996 Luca Cabibbo Architetture Software Dispensa ASW 420 ottobre 2014 Tutti sanno che una certa cosa è impossibile da realizzare, finché arriva uno sprovveduto che non lo sa e la inventa. Albert Einstein 1

Dettagli

Internet e protocollo TCP/IP

Internet e protocollo TCP/IP Internet e protocollo TCP/IP Internet Nata dalla fusione di reti di agenzie governative americane (ARPANET) e reti di università E una rete di reti, di scala planetaria, pubblica, a commutazione di pacchetto

Dettagli

INDICE. Indice. Introduzione

INDICE. Indice. Introduzione V Indice Introduzione XIII Capitolo 1 La programmazione multithread 1 1.1 Cosa sono i thread 2 Utilizzare i thread per dare una possibilità ad altri task 9 Avvio ed esecuzione dei thread 10 Esecuzione

Dettagli

Università degli Studi di Napoli Federico II Facoltà di Ingegneria Corso di Laurea Specialistica in Ingegneria Informatica.

Università degli Studi di Napoli Federico II Facoltà di Ingegneria Corso di Laurea Specialistica in Ingegneria Informatica. Università degli Studi di Napoli Federico II Facoltà di Ingegneria Corso di Laurea Specialistica in Ingegneria Informatica Corso di Sistemi Distribuiti Prof. Stefano Russo Caratterizzazionedei SistemiDistribuiti

Dettagli

Programmazione concorrente in Java. Dr. Paolo Casoto, Ph.D. - 2012 1

Programmazione concorrente in Java. Dr. Paolo Casoto, Ph.D. - 2012 1 + Programmazione concorrente in Java 1 + Introduzione al multithreading 2 La scomposizione in oggetti consente di separare un programma in sottosezioni indipendenti. Oggetto = metodi + attributi finalizzati

Dettagli

Sistemi avanzati di gestione dei Sistemi Informativi

Sistemi avanzati di gestione dei Sistemi Informativi Esperti nella gestione dei sistemi informativi e tecnologie informatiche Sistemi avanzati di gestione dei Sistemi Informativi Docente: Email: Sito: Eduard Roccatello eduard@roccatello.it http://www.roccatello.it/teaching/gsi/

Dettagli

Evoluzione dei sistemi operativi (5) Evoluzione dei sistemi operativi (4) Classificazione dei sistemi operativi

Evoluzione dei sistemi operativi (5) Evoluzione dei sistemi operativi (4) Classificazione dei sistemi operativi Evoluzione dei sistemi operativi (4) Sistemi multiprogrammati! più programmi sono caricati in contemporaneamente, e l elaborazione passa periodicamente dall uno all altro Evoluzione dei sistemi operativi

Dettagli

Architettura SW Definizione e Notazioni

Architettura SW Definizione e Notazioni Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Stili Architetturali E. TINELLI Architettura SW Definizione e Notazioni Definizione ANSI/IEEE Std Std1471-2000

Dettagli

Table of Contents. Insegnamento: Sistemi Distribuiti - 6 cfu LM Ing. Informatica Docente: Prof. Marcello Castellano

Table of Contents. Insegnamento: Sistemi Distribuiti - 6 cfu LM Ing. Informatica Docente: Prof. Marcello Castellano Insegnamento: Sistemi Distribuiti - 6 cfu LM Ing. Informatica Docente: Prof. Marcello Castellano Table of Contents Definizione di Sistema Distribuito - 4 Obiettivi Principali di un S.D. - 7 Tipi di Sistemi

Dettagli

Centralizzata Monolitica anni Reti Client Server anni Internet The network is the computer

Centralizzata Monolitica anni Reti Client Server anni Internet The network is the computer Distributed Object C o m p utin g "!$#&% ')(+*,#&-).0/2143657*98:.;8

Dettagli

Reti e Domini Windows 2000. Corso di Amministrazione di Reti A.A. 2002/2003

Reti e Domini Windows 2000. Corso di Amministrazione di Reti A.A. 2002/2003 Reti e Domini Windows 2000 Corso di Amministrazione di Reti A.A. 2002/2003 Materiale preparato utilizzando dove possibile materiale AIPA http://www.aipa.it/attivita[2/formazione[6/corsi[2/materiali/reti%20di%20calcolatori/welcome.htm

Dettagli

Il File System. È la componente del S.O. che si occupa della gestione della memoria di massa e dell organizzazione logica dei dati

Il File System. È la componente del S.O. che si occupa della gestione della memoria di massa e dell organizzazione logica dei dati Il File System È la componente del S.O. che si occupa della gestione della memoria di massa e dell organizzazione logica dei dati Le operazioni supportate da un file system sono: eliminazione di dati modifica

Dettagli

JNDI. Massimo Merro Programmazione di Rete 214 / 229

JNDI. Massimo Merro Programmazione di Rete 214 / 229 JNDI Abbiamo già visto come i registri RMI espletino un servizio di Naming attraverso cui vengono associati nomi simbolici a referenze a server remoti. Esistono comunque altri servizi di naming: COS (Common

Dettagli

Programmazione distribuita

Programmazione distribuita Programmazione distribuita 1 Architettura client-server È il modo classico di progettare applicazioni distribuite su rete Server offre un servizio "centralizzato" attende che altri (client) lo contattino

Dettagli

Introduzione ai sistemi operativi

Introduzione ai sistemi operativi Introduzione ai sistemi operativi Che cos è un S.O.? Shell Utente Utente 1 2 Utente N Window Compilatori Assembler Editor.. DB SOFTWARE APPLICATIVO System calls SISTEMA OPERATIVO HARDWARE Funzioni di un

Dettagli

Comunicazione tra Computer. Protocolli. Astrazione di Sottosistema di Comunicazione. Modello di un Sottosistema di Comunicazione

Comunicazione tra Computer. Protocolli. Astrazione di Sottosistema di Comunicazione. Modello di un Sottosistema di Comunicazione I semestre 04/05 Comunicazione tra Computer Protocolli Prof. Vincenzo Auletta auletta@dia.unisa.it http://www.dia.unisa.it/professori/auletta/ Università degli studi di Salerno Laurea in Informatica 1

Dettagli

5. Traduzione degli indirizzi di rete in indirizzi fisici: ARP

5. Traduzione degli indirizzi di rete in indirizzi fisici: ARP 5. Traduzione degli indirizzi di rete in indirizzi fisici: ARP 5.1. Introduzione Due macchine si parlano solo se conoscono l'indirizzo fisico di sottorete Due applicazioni si parlano solo se conoscono

Dettagli

Sistemi avanzati di gestione dei Sistemi Informativi

Sistemi avanzati di gestione dei Sistemi Informativi Esperti nella gestione dei sistemi informativi e tecnologie informatiche Sistemi avanzati di gestione dei Sistemi Informativi Docente: Email: Sito: Eduard Roccatello eduard@roccatello.it http://www.roccatello.it/teaching/gsi/

Dettagli

Tecnologia di un Database Server (centralizzato) Gestione del buffer

Tecnologia di un Database Server (centralizzato) Gestione del buffer Buffer Basi di Dati / Complementi di Basi di Dati 1 Tecnologia di un Database Server (centralizzato) Gestione del buffer Angelo Montanari Dipartimento di Matematica e Informatica Università di Udine Buffer

Dettagli

UDP. Livello di Trasporto. Demultiplexing dei Messaggi. Esempio di Demultiplexing

UDP. Livello di Trasporto. Demultiplexing dei Messaggi. Esempio di Demultiplexing a.a. 2002/03 Livello di Trasporto UDP Descrive la comunicazione tra due dispositivi Fornisce un meccanismo per il trasferimento di dati tra sistemi terminali (end user) Prof. Vincenzo Auletta auletta@dia.unisa.it

Dettagli

Programmazione ad Oggetti. Java Parte I

Programmazione ad Oggetti. Java Parte I Programmazione ad Oggetti Java Parte I Overview Caratteristiche generali 1 Caratteristiche generali Un moderno linguaggio orientato agli oggetti Pensato per lo sviluppo di applicazioni che devono essere

Dettagli

Organizzazioni nel Grid Computing

Organizzazioni nel Grid Computing Il ruolo delle Organizzazioni nel Grid Computing Un primo sguardo a Globus - Parte 5 Organizzazioni di Grid Computing Panoramica sui prodotti software Primo sguardo a Globus Dott. Marcello CASTELLANO La

Dettagli

Sviluppo Applicazioni Mobile Lezione 12 JDBC. Dr. Paolo Casoto, Ph.D - 2012

Sviluppo Applicazioni Mobile Lezione 12 JDBC. Dr. Paolo Casoto, Ph.D - 2012 + Sviluppo Applicazioni Mobile Lezione 12 JDBC + Cosa vediamo nella lezione di oggi Oggi analizzeremo insieme una specifica tecnologia Java per l accesso e la manipolazione di basi di dati relazionali

Dettagli

Griglie e Sistemi di Elaborazione Ubiqui. Grid File Systems. Requisiti, Funzionalità e Architettura. Grid File System: Requisiti

Griglie e Sistemi di Elaborazione Ubiqui. Grid File Systems. Requisiti, Funzionalità e Architettura. Grid File System: Requisiti Griglie e Sistemi di Elaborazione Ubiqui Grid File Systems Requisiti, Funzionalità e Architettura Griglie e Sistemi Ubiqui - D. Talia - UNICAL 1 Grid File System: Requisiti Name Space Gerarchico Logico

Dettagli

Classificazione del software

Classificazione del software Classificazione del software Classificazione dei software Sulla base del loro utilizzo, i programmi si distinguono in: SOFTWARE Sistema operativo Software applicativo Sistema operativo: una definizione

Dettagli

Sistemi Web Tolleranti ai Guasti

Sistemi Web Tolleranti ai Guasti Sistemi Web Tolleranti ai Guasti Candidato: Paolo Romano Relatore: Prof. Salvatore Tucci Correlatore: Prof. Bruno Ciciani Sommario Il problema: garantire semantica exactly once alle transazioni Web. Sistema

Dettagli