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

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

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 & 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Architetture per le applicazioni web-based. Mario Cannataro

Architetture per le applicazioni web-based. Mario Cannataro Architetture per le applicazioni web-based Mario Cannataro 1 Sommario Internet e le applicazioni web-based Caratteristiche delle applicazioni web-based Soluzioni per l architettura three-tier Livello utente

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

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

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

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

Table of Contents. Definizione di Sistema Distribuito 15/03/2013

Table of Contents. Definizione di Sistema Distribuito 15/03/2013 Insegnamento: Sistemi Distribuiti - 6 cfu LM Ing. Informatica Docente: Prof. Marcello Castellano Table of Contents Definizione di Sistema Distribuito - 4-7 - 13 Definizioni e Principali Caratteristiche

Dettagli

Interoperabilità e cooperazione applicativa tra sistemi informativi

Interoperabilità e cooperazione applicativa tra sistemi informativi Interoperabilità e cooperazione applicativa tra sistemi informativi Michele Ruta Dipartimento di Ingegneria Elettrica e dell Informazione Politecnico di Bari 1di 29 Indice Introduzione ai Port Community

Dettagli

RPC Birrel e Nelson (1984) partendo da quanto usato in Xerox, Spice, Sun, HP, etc.

RPC Birrel e Nelson (1984) partendo da quanto usato in Xerox, Spice, Sun, HP, etc. REMOTE PROCEDURE CALL (RPC) estensione del normale meccanismo di chiamata a procedura, adatta per il modello cliente servitore nel distribuito approccio di alto livello APPROCCIO di livello applicativo

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

Analisi, progettazione e implementazione di un repository di componenti distribuite in Java basato su JNDI.

Analisi, progettazione e implementazione di un repository di componenti distribuite in Java basato su JNDI. UNIVERSITÀ DEGLI STUDI DI ROMA LA SAPIENZA TESI DI LAUREA IN SCIENZE DELL INFORMAZIONE Analisi, progettazione e implementazione di un repository di componenti distribuite in Java basato su JNDI. Relatore:

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

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 DEI SISTEMI DI ELABORAZIONE

ARCHITETTURE DEI SISTEMI DI ELABORAZIONE ARCHITETTURE DEI SISTEMI DI ELABORAZIONE 1 SISTEMI ACCENTRATI CARATTERISTICHE Sistemi proprietari Monocultura Scarsa diffusione informatica Backlog 2 Soluzione centralizzata TERMINALE TERMINALE ELABORATORE

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

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

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

Architetture Software Milano

Architetture Software Milano Architetture Software Approccio tradizionale allo sviluppo I limiti del modello requisiti, progetto, implementazione Il concetto di architettura software Il concetto di stile architetturale I principali

Dettagli

Architettura Tecnica i. Architettura Tecnica

Architettura Tecnica i. Architettura Tecnica i Architettura Tecnica ii Copyright 2005-2011 Link.it s.r.l. iii Indice 1 Scopo del documento 1 1.1 Abbreviazioni..................................................... 1 2 Overview 1 2.1 La PdD........................................................

Dettagli

PROGETTO DI UN MIDDLEWARE PER L ACCESSO REMOTO A UN REPOSITORY

PROGETTO DI UN MIDDLEWARE PER L ACCESSO REMOTO A UN REPOSITORY Giampiero Allamprese 0000260193 PROGETTO DI UN MIDDLEWARE PER L ACCESSO REMOTO A UN REPOSITORY Reti di Calcolatori LS prof. Antonio Corradi A.A. 2007/2008 ABSTRACT L obiettivo di questo progetto è la realizzazione

Dettagli

Programmabilità di rete con l'infrastruttura Cisco basata sulle applicazioni

Programmabilità di rete con l'infrastruttura Cisco basata sulle applicazioni White paper Programmabilità di rete con l'infrastruttura Cisco basata sulle applicazioni Panoramica Questo documento analizza il supporto alla programmabilità nell'infrastruttura ACI (Application Centric

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

Progettazione di Sistemi Interattivi. Gli strati e la rete. Struttura e supporti all implementazione di applicazioni in rete (cenni)

Progettazione di Sistemi Interattivi. Gli strati e la rete. Struttura e supporti all implementazione di applicazioni in rete (cenni) Progettazione di Sistemi Interattivi Struttura e supporti all implementazione di applicazioni in rete (cenni) Docente: Daniela Fogli Gli strati e la rete Stratificazione da un altro punto di vista: i calcolatori

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

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

UX model e Architetture di SI web-based. B. Pernici D. Ardagna

UX model e Architetture di SI web-based. B. Pernici D. Ardagna UX model e Architetture di SI web-based B. Pernici D. Ardagna Conallen, cap. 7,9 Bibliografia Modellazione concettuale: UX model Primo passo di analisi UX: user experience Schermate Modellare la navigazione,

Dettagli

Santoro Umberto Roberto. Corba e Java

Santoro Umberto Roberto. Corba e Java Santoro Umberto Roberto Corba e Java Sommario Nell era di Internet e delle grandi Intranet aziendali, il modello computazionale dominante è chiaramente quello distribuito. Un tipico ambiente distribuito

Dettagli

Logbus-ng: a software logging bus for Field Failure Data Analysis in distributed systems Anno Accademico 2009-2010

Logbus-ng: a software logging bus for Field Failure Data Analysis in distributed systems Anno Accademico 2009-2010 tesi di laurea Logbus-ng: a software logging bus for Field Failure Data Analysis in Anno Accademico 2009-2010 relatore Ch.mo prof. Domenico Cotroneo Ch.mo prof. Marcello Cinque correlatore Ch.mo Ing. Antonio

Dettagli

Università di Bergamo Facoltà di Ingegneria INGEGNERIA DEL SOFTWARE. Paolo Salvaneschi C1_2 V3.3. Connettori

Università di Bergamo Facoltà di Ingegneria INGEGNERIA DEL SOFTWARE. Paolo Salvaneschi C1_2 V3.3. Connettori Università di Bergamo Facoltà di Ingegneria INGEGNERIA DEL SOFTWARE Paolo Salvaneschi C1_2 V3.3 Connettori Il contenuto del documento è liberamente utilizzabile dagli studenti, per studio personale e per

Dettagli

Architetture di sistema

Architetture di sistema Università di Bergamo Facoltà di Ingegneria Applicazioni Internet B Paolo Salvaneschi B1_1 V1.6 Architetture di sistema Il contenuto del documento è liberamente utilizzabile dagli studenti, per studio

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

Ingegneria del Software UML - Unified Modeling Language

Ingegneria del Software UML - Unified Modeling Language Ingegneria del Software UML - Unified Modeling Language Obiettivi. Presentare un approccio visuale alla progettazione. Illustrare i vantaggi dell utilizzo di diagrammi nella fase di progettazione. Rispondere

Dettagli

Middleware vari. L'obbiettivo quindi è quello di fornire dei servizi con qualità!

Middleware vari. L'obbiettivo quindi è quello di fornire dei servizi con qualità! Middleware vari 2 Col termine middleware si indica tutto ciò che è in mezzo tra l'utente e tutte le risorse locali di sistema operativo e di tecnologie di scelte locali. In realtà il termine middleware

Dettagli

Architetture basate su componenti

Architetture basate su componenti Luca Cabibbo Architetture Software Architetture basate su componenti Dispensa ASW 440 ottobre 2014 Affida le cose speciali agli specialisti. Robert Spinrad 1 -Fonti [POSA4] Pattern-Oriented Software Architecture

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

Il linguaggio Java. Oggetto remoto. Remote Method Invocation (RMI) Oggetto remoto: oggetto i cui metodi possono essere invocati attraverso la rete

Il linguaggio Java. Oggetto remoto. Remote Method Invocation (RMI) Oggetto remoto: oggetto i cui metodi possono essere invocati attraverso la rete Il linguaggio Java Remote Method Invocation (RMI) Oggetto remoto Oggetto remoto: oggetto i cui metodi possono essere invocati attraverso la rete Client Server 2 Schema di principio oggetto client oggetto

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

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

Architetture Web. parte 1. Programmazione in Ambienti Distribuiti A.A. 2003-04

Architetture Web. parte 1. Programmazione in Ambienti Distribuiti A.A. 2003-04 Architetture Web parte 1 Programmazione in Ambienti Distribuiti A.A. 2003-04 Architetture Web (1) Modello a tre livelli in cui le interazioni tra livello presentazione e livello applicazione sono mediate

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

OLTRE AJAX CON COMET Lightstreamer e la push technology per il Web 2.0. Alessandro Alinone CTO Lightstreamer

OLTRE AJAX CON COMET Lightstreamer e la push technology per il Web 2.0. Alessandro Alinone CTO Lightstreamer OLTRE AJAX CON COMET Lightstreamer e la push technology per il Web 2.0 Alessandro Alinone CTO Lightstreamer Un Web 2.0 molto pulito AJAX Colgate-Palmolive --- Jesse James Garrett 2005 COMET Procter & Gamble

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

Web services. 25/01/10 Web services

Web services. 25/01/10 Web services Web services Tecnologia per il computing distribuito standard W3C non dissimile da RMI, CORBA, EJB... Relazione con il Web Websites for humans, Web Services for software :-) un Web service ha un indirizzo

Dettagli

Organizzazione del testo

Organizzazione del testo Questo testo è un introduzione allo standard CORBA (Common Object Request Broker Architecture) e all architettura di riferimento OMA (Object Management Architecture), per lo sviluppo di sistemi software

Dettagli

Implementazione del File System

Implementazione del File System Implementazione del file system Implementazione del File System Struttura del file system. Realizzazione del file system. Implementazione delle directory. Metodi di allocazione. Gestione dello spazio libero.

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

JDBC: Introduzione. Java Database Connectivity (JDBC): parte 1. Schema dei legami tra le classi principali. Principali classi/interfacce di JDBC

JDBC: Introduzione. Java Database Connectivity (JDBC): parte 1. Schema dei legami tra le classi principali. Principali classi/interfacce di JDBC JDBC: Introduzione Java Database Connectivity (JDBC): parte 1 Gianluca Moro DEIS - Università di Bologna gmoro@deis.unibo.it Java Database Connectivity è il package Java per l accesso a database relazionali

Dettagli

Architetture di sistema

Architetture di sistema Università di Bergamo Facoltà di Ingegneria Applicazioni Internet B Paolo Salvaneschi B1_1 V1.7 Architetture di sistema Il contenuto del documento è liberamente utilizzabile dagli studenti, per studio

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

Messaging (stile architetturale) e integrazione di applicazioni

Messaging (stile architetturale) e integrazione di applicazioni Luca Cabibbo Architetture Software Messaging (stile architetturale) e integrazione di applicazioni Dispensa ASW 430 ottobre 2014 Una specifica d interfaccia di buona qualità deve essere semplice, non ambigua,

Dettagli

Programmazione CORBA in Java

Programmazione CORBA in Java Programmazione CORBA in Java Ing. Andrea Santoro http://www.dis.uniroma1.it/~santoroa santoro@dis.uniroma1.it (codice preparato dall ing. Alessandro Termini) Overview Naming Service Motivazioni Name Service

Dettagli

JDBC di base. Le classi/interfacce principali di JDBC

JDBC di base. Le classi/interfacce principali di JDBC JDBC di base Java Database Connectivity è il package Java per l accesso a database relazionali il package contiene interfacce e classi astratte completa indipendenza del codice dal tipo di database o di

Dettagli

Struttura della lezione. Lezione 9 Architetture dei sistemi distribuiti (2) Il valore aggiunto di una rete di N utenti

Struttura della lezione. Lezione 9 Architetture dei sistemi distribuiti (2) Il valore aggiunto di una rete di N utenti Struttura della lezione Lezione 9 Architetture dei sistemi distribuiti (2) Vittorio Scarano Corso di Programmazione Distribuita (2003-2004) Laurea di I livello in Informatica Università degli Studi di

Dettagli

Introduzione ai Sistemi Distribuiti

Introduzione ai Sistemi Distribuiti Università degli Studi di Roma Tor Vergata Facoltà di Ingegneria Introduzione ai Sistemi Distribuiti Corso di Sistemi Distribuiti Valeria Cardellini Anno accademico 2008/09 Definizioni di SD Molteplici

Dettagli

Web Services con Axis Delia Di Giorgio Anna Celada 1 marzo 2005

Web Services con Axis Delia Di Giorgio Anna Celada 1 marzo 2005 Sommario Web Services con Axis Delia Di Giorgio Anna Celada 1 marzo 2005 Introduzione.................................................................................. 1 SOAP........................................................................................

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

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

Sistemi Distribuiti. Informatica B. Informatica B

Sistemi Distribuiti. Informatica B. Informatica B Sistemi Distribuiti Introduzione Che cos è un sistema distribuito? Un sistema distribuito è una collezione di computer indipendenti che appare all utente come un solo sistema coerente Da notare: le macchine

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

Le caratteristiche di interoperabilità del Terrapack 32 M

Le caratteristiche di interoperabilità del Terrapack 32 M I T P E l e t t r o n i c a Le caratteristiche di interoperabilità del Terrapack 32 M M. Guerriero*, V. Ferrara**, L. de Santis*** * ITP Elettronica ** Dipartimento di Ingegneria Elettronica Univ. La Sapienza

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

Network Management. Corso Reti ed Applicazioni Mauro Campanella

Network Management. Corso Reti ed Applicazioni Mauro Campanella Network Management Corso Reti ed Applicazioni Mauro Campanella Cos è il network management? Gli autonomous system (o network ): centinaia o migliaia di oggetti hardware e software che interagiscono Come

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

Dettaglio dei corsi in aula

Dettaglio dei corsi in aula L offerta formativa Dettaglio dei corsi in aula Software Engineering Object Oriented Analysis and Design: fondamenti e principi dell object orientation. Dall analisi alla progettazione. I Design Pattern.

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

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

INTRODUZIONE. Motivazioni e Obbiettivi

INTRODUZIONE. Motivazioni e Obbiettivi INTRODUZIONE Motivazioni dei sistemi distribuiti Caratteristiche generali Alcuni richiami sui database centralizzati Standardizzazione dei dati (ANSI/SPARC) Funzioni dei DBMS relazionali Problematiche

Dettagli

Web Services e Grid Services. OGSA e WSRF. Sommario. Page 1

Web Services e Grid Services. OGSA e WSRF. Sommario. Page 1 Sommario Web Services e Grid Services OGSA e WSRF SOA Grid: Evoluzione OGSA - Open Grid Services Architecture WSRF Web Services Resource Framework Web services Servizi stateless Gestione dello stato Grid

Dettagli

Web Services e Grid Services. OGSA e WSRF

Web Services e Grid Services. OGSA e WSRF Web Services e Grid Services OGSA e WSRF Sommario SOA Grid: Evoluzione OGSA - Open Grid Services Architecture WSRF Web Services Resource Framework Web services Servizi stateless Gestione dello stato Grid

Dettagli

Activation In sintesi: è inutile avere attivi degli oggetti se non vengono utilizzati

Activation In sintesi: è inutile avere attivi degli oggetti se non vengono utilizzati Activation In generale i Sistemi ad oggetti distribuiti sono progettati per lavorare con oggetti persistenti. Dato che questi sistemi saranno composti da migliaia (forse milioni) di tali oggetti, sarebbe

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

Sistema Operativo Compilatore

Sistema Operativo Compilatore MASTER Information Technology Excellence Road (I.T.E.R.) Sistema Operativo Compilatore Maurizio Palesi Salvatore Serrano Master ITER Informatica di Base Maurizio Palesi, Salvatore Serrano 1 Il Sistema

Dettagli