CORBA 3.0

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 è l’ORB (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 dall’OMG è stato BOA • BOA fornisce solo servizi di base che permettono la creazione e l’implementazione 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 l’ORB e e le applicazioni server

7. POA - Basics 1 • Il cliente invia la richiesta (invokes the request) mediante una Object Reference (OR) che specifica l’oggetto target • La richiesta è ricevuta dall’ORB del server • parte di essa contiene un ID detto Object Key (OK) che identifica univocamente il CO nell’ambito dell’applicazione 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 l’applicazione per provvedere ad un servant relativo al target object ID, o usarne uno di default stabilito dall’applicazione stessa • in ogni caso POA smista la richiesta all’appl.

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 nell’ambito di tutte le applicazioni server.

10. POA - Basics 4 • All’ atto della creazione di un CO l’ OID viene fornito dal’applicazione 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 l’oggetto 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 dell’ORB. Una volta distrutto il POA che ha creato un TCO non può più essere riattivato sempificando le operazioni dell’ORB.

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 un’applicazione server di usare più thread per servire più richieste concorrentemente

15. CORBA & OMA in ETERPRISE COMPUTING Dopo Corba 2.0 l’OMG 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 un’ampia 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 l’impresa, oggetti standard per funzioni standard, condivisibilità ecc.

20. UML e MOF: Supporting Analysis and Design Il modeling è il primo passo chiave per costruire sistemi software di impresa con requisiti industrial-strength. Questo ha portato l’OMG 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 www.corba.org

21. CORBA Computing Model Passaggio di una richiesta da un client ad un object implementation (vrdi figura): • entrambi client e implementation sono isolati dall’ORB tramite una OMG/ISO IDL interface. • La richiesta non passa direttamente dal cliente all’implementazione 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 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 un’interfaccia 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 un’estensione 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 disoftware CORBAcomponent L’ambiente CORBAcomponents è sicuro, persistente e transactional.

25. Event-Driven programming Molti task di programmazione richiedono l’integrazione 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 dell’ambiente. • 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).