1 CORBA 3.0 Nuove Caratteristiche

2 Evoluzione di CORBA Introdotto nel 1991 come astrazione per la programmazione di oggetti distribuiti permette di integrare applicazioni distinte in un sistema distribuito ed omogeneo il cuore di ogni sistema basato su CORBA è lORB (Object Request Broker).

3 Da CORBA 1 a CORBA 3 EVOLUZIONE di CORBA CORBA 2 aggiunge (1995) –lo Standard General Inter-ORB Protocol (GIOP) e relativa specifica di implementazione sul TCP/IP –L Internet Inter-ORB Protocol (IIOP) CORBA 3 aggiunge (1998) –Il Portable Object Adapter (POA) –CORBA Messaging –Objects By Value

4 Portable Object Adapter POA RUOLO di POA Mediare tra gli Oggetti CORBA (CO) e il mondo delle implementazioni, nei vari linguaggi di progr. dette Servants. In particolare Creare Oggetti CORBA (CO) Smistare le richieste fatte ai singoli CO Dispatching delle richieste ai servant che incarnano o implementano CO target Attivare disattivare CO

5 POA - Motivazioni Fino a CORBA 2.1 il solo standard Object Adapter definito dallOMG è stato BOA BOA fornisce solo servizi di base che permettono la creazione e limplementazione di CO Molte feature mancavano o erano definite in modo ambiguo con conseguente proliferazione di versioni proprietarie tra loro incompatibili

6 POA - Basics POA media tra lORB e e le applicazioni server

7 POA - Basics 1 Il cliente invia la richiesta (invokes the request) mediante una Object Reference (OR) che specifica loggetto target La richiesta è ricevuta dallORB del server –parte di essa contiene un ID detto Object Key (OK) che identifica univocamente il CO nellambito dellapplicazione server –Essendovi più POA la OK aiuta ORB nel dispatching verso il POA opportuno.

8 POA - Basics 2 Il POA usa una parte della OK detta Object ID (OID) per associare il Target Object e il servant (livello di linguaggio programmativo) –le associazioni possono essere memorizzate in una map oppure: –POA può chiamare lapplicazione per provvedere ad un servant relativo al target object ID, o usarne uno di default stabilito dallapplicazione stessa in ogni caso POA smista la richiesta allappl.

9 POA - Basics 3 Il POA interagisce principalmente con tre entità: –Due l Object Reference - e l Object ID usate per identificare –La terza il Servant che implementa i CO Una server Application prima chiede a POA di creare un nuovo CO - il POA restitusce una Object Reference che identifica univoc. Il CO nellambito di tutte le applicazioni server.

10 POA - Basics 4 All atto della creazione di un CO l OID viene fornito dalapplicazione stessa o dal POA che identifica in modo unico il CO nel proprio scope Un Servant è detto Incarnare (o to provide a body) di un CO. In definitiva la richiesta per un CO viene eseguita dal suo Servant. Nel caso di uso di C++ e Java i Servant sono istanze di classi del linguaggio.

11 Oggetti Persistenti e Transienti Una delle caratteristiche migliori di CORBA è il meccanismo di attivazione automatica e trasparente di oggetti. Se un applicazione Client emette una richiesta ad un Target Object non in esecuzione o non attivato, CORBA chiede alle implementazioni di ORB di attivare un processo server per tale oggetto (se necessario) e quindi di attivare loggetto stesso.

12 Oggetti Persistenti e Transienti 2 Ogni attivazione di processo server e di target object è trasparente ai rispettivi clienti Gli Oggetti CORBA che hanno un ciclo di vita che trascende quello del processo specifico che li crea o attiva sono detti persistenti. E anche utile avere oggetti il cui ciclo di vita è limitato da quello del processo o dell Object Adapter che li crea.

13 Oggetti Persistenti e Transienti 3 POA supporta due tipi di CO –Persistent objects (nella versione originale) –Transient objects (TCO) il cui ciclo di vita è limitato da quello del POA in cui viene creato Gli Oggetti transient richiedono meno bookkeeoing da parte dellORB. Una volta distrutto il POA che ha creato un TCO non può più essere riattivato sempificando le operazioni dellORB.

14 POA aspetti ulteriori POA supporta anche i seguenti meccanismi –Explicit and on-demand activation –Separation of servant and CORBA object life cycles –Different policies of multithreading CORBA multithreading –permette ad unapplicazione server di usare più thread per servire più richieste concorrentemente

15 CORBA & OMA in ETERPRISE COMPUTING Dopo Corba 2.0 lOMG si è mosso in diverse direzioni: Multiple interfaces per object, Object passed by value, Beans-like component model, Real-time support Fault-tolerance Embedded CORBA

16 USO di IDL Le imprese operanti nel mercati verticali hanno iniziato ad usare IDL per descrivere le specifiche di oggetti standard da usare in modo pubblico e condiviso. OMG ha ampliato il proprio scopo con un allargamento di orizzonti a: Finanza /Asicurazioni Commercio Elettronico, Healthcare, Manufactoring, Telecomunicazioni Trasporti Life Science & Research Business Objects

17 OMG Specification Suite Come risultato si è avuta unampia gamma di specifiche OMG

18 ARCHITECTURAL OVERVIEW L architettura OMG offre: Supporto per analisi e design: UML e MOF Basic o-o computing model: ORB; OMG/ISO IDL e suo mapping verso C,C++,Java,Smalltalk,Cobol e Ada Distribuzione: il protocollo GIOP e il suo mapping verso TCP/IP e varie forme alternative di messaging e asynchronous invocation Component Model: CORBA Components and Scripting; multiple interfaces; oggetti passati per valore Modi specializzati: real-time, fault-tolerance, embedded CORBA

19 ARCHITECTURAL OVERVIEW (cont) CORBAservices. Basic services for distributed object applications: naming and trader services, event & notification, Object Transaction Serv. (OTS), Security serv. Horizontal CORBAfacilities: System Management, print spooling, etc.. Vertical Market (Domain) CORBAfacilities: Supporto per limpresa, oggetti standard per funzioni standard, condivisibilità ecc.

20 UML e MOF: Supporting Analysis and Design modeling industrial-strength. Unified Modeling Language (UML) Il modeling è il primo passo chiave per costruire sistemi software di impresa con requisiti industrial-strength. Questo ha portato lOMG a promuovere l Unified Modeling Language (UML) un linguaggio visuale per lo scambio di modelli di sviluppo software ben definiti UML è definito nella guida UML Notation Guide

21 CORBA Computing Model richiestaclientobject implementation Passaggio di una richiesta da un client ad un object implementation (vrdi figura): entrambi client e implementation sono isolati dallORB tramite una OMG/ISO IDL interface. La richiesta non passa direttamente dal cliente allimplementazione ma è sempre gestita da ORB –ogni richiesta sia locale che remota ha sempre la stessa forma –I dettagli per la distribuzione risedono in ORB

22 CORBA Distribution Model richiestaclientobject implementation ORB-to-ORB Il passaggio di una richiesta èda un client ad un object implementation nel caso distribuito (figura) si basa sulla comunicazione ORB-to-ORB. IDL supporta la distribuzione in vari modi. In particolare GIOP (lo Standard general Inter ORB Protocol) specifica tutti gli aspetti di interoperabilità.

23 COMPONENT PROGRAMMING Si basa sullo sviluppo di componenti che implementano uninterfaccia ben definita (esempio: interfacce CORBA implementate in IDL). La base è costituita dalle interfacce che una componente esporta verso il mondo esterno. Ciascuna di queste è un socket su cui altre componenti ed applicazioni si agganciano (plug-in). La programmazione basata su componenti separa la costruzione di unità computazionali dalla loro configurazione tramite connettori in un sistema computazionalmente complesso

24 CORBA Component Model (CORBAbeans) Rappresenta unestensione naturale del modello CORBA object. Un container environment che incapsula –transactionality –security –persistence –provvede un interfaccia ed event resolution Integrazione con Entreprise JavaBeans Software distribution format che facilita il marketing di software CORBAcomponent Lambiente CORBAcomponents è sicuro, persistente e transactional.

25 Event-Driven programming Molti task di programmazione richiedono lintegrazione di fatti (eventi) che avvengono in modo asincrono: essi non avvengono a tempi fissi e controllati ed il sistema deve essere pronto a trattarli in ogni momento essi avvengano. Ad esempio una GUI non può obbligare un utente a premere un tasto del mause dopo ogni spostamento.

26 Event-Driven programming The most commonly used technique for doing this is called event-based programming, and it is such a good coding idiom that it is used in nearly every practical programming language in use today. Of course, some languages offer better support for it than others... The basic idea is that you have a queue of possible events, and as the environment (i.e. the world outside the program) does things, so events are generated and added to the queue. Meanwhile, the program sits there, grabbing events off the queue and doing whatever it takes to deal with them, usually by way of a gigantic [switch] statement (or whatever that language's equivalent is.)

27 Event-Driven programming Event-driven programming è quindi uno stile di programmazione in cui il programma è driven da eventi esterni. I programmi Event-driven sono composti da piccole porzioni di codice dette: event handlers, attivati in risposta a eventi esterni un dispatcher, che attiva gli event handlers, sulla base di eventuali event queue che memorizzano gli eventi non ancore processati.

28 Event-Driven programming cont. Event: - Unlike traditional programs, which follow their own control flow pattern, onlysometimes changing course at branch points, the control flow of event-driven programs is largely driven by external events. event handler: an event handler is the code that is executed when an event occurs. See also event.

29 Event-Driven programming cont. a reactive system is an event-driven system interrupt-driven is event-driven thus reactive systems | | interrupt-driven systems | ==> event-driven systems | signal-driven systems |

30 Event-Driven programming cont. In molti casi gli event handlers possono attivare (to trigger) a loro volta nuovi eventi, provocando una cascata di eventi. Event-driven programming rinforza flessibilità e asincronia e tende ad essere praticamente modeless. Le graphical user interface sono solitamente programmate in stile event-driven. Gli Operating Systems costituiscono un altro esempio di event-driven programs.

31 Interrupt-Driven programming The style of programming where the program is not in control all the time but rather responds to interrupts or signals in order to get started. At the lowest level, interrupt handlers act as direct event handlers for hardware events, with the CPU hardware performing the role of the dispatcher.

32 Sistemi Reattivi (Reactive Systems) Un sistema reattivo è un sistema event-driven che interagisce continuamente con l ambiente (environment) reagendo agli stimoli che da esso gli pervengono. Si assume che i sistemi reattivi: eseguano con una velocità mai sopraffatta da quella dellambiente. usualmente non terminino mai e quindi non siano facilmente caratterizzabili da semplici funzioni che partendo da uno stato iniziale li portino ad uno stato finale.

33 Sistemi Reattivi (Cont.) Un sistema real-time è un sistema reattivo che deve rispettare vincoli temporali (timing constraints). Il termine reactive è più specifico di event- driven (piuttosto overloaded in letteratura) ma è più generale di soft real-time e near real- time: poiché esso non si riferisce a vincoli temporali da rispettare in real-time. I sistemi reattivi più semplici vengono spesso programmati come macchine a stati finiti (automi).

34 Sistemi Reattivi (Cont.) I linguaggi sincroni (synchronous languages) sistema real-time è un sistema reattivo che deve rispettare vincoli temporali (timing constraints). Il termine reactive è più specifico di event- driven (piuttosto overloaded in letteratura) ma è più generale di soft real-time e near real- time: poiché esso non si riferisce a vincoli temporali da rispettare in real-time. I sistemi reattivi più semplici vengono spesso programmati come macchine a stati finiti (automi).

35 Sistemi Reattivi (Cont.) I linguaggi sincroni (synchronous languages) sistema real-time è un sistema reattivo che deve rispettare vincoli temporali (timing constraints). Il termine reactive è più specifico di event- driven (piuttosto overloaded in letteratura) ma è più generale di soft real-time e near real- time: poiché esso non si riferisce a vincoli temporali da rispettare in real-time. I sistemi reattivi più semplici vengono spesso programmati come macchine a stati finiti (automi).