Transcript CORBA 3.0

CORBA 3.0
Nuove Caratteristiche
1
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).
2
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
3
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
4
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
5
POA - Basics
• POA media tra l’ORB e e le applicazioni server
6
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.
7
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.
8
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.
9
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.
10
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.
11
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.
12
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.
13
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
14
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
15
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
16
OMG Specification Suite
Come risultato si è avuta un’ampia gamma di specifiche
OMG
17
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
18
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.
19
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
20
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
21
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à.
22
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
23
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 di
software CORBAcomponent
L’ambiente CORBAcomponents è sicuro, persistente e
transactional.
24
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.
25
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.)
26
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.
27
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.
28
Event-Driven programming cont.
a reactive system is an event-driven system
interrupt-driven is event-driven thus
reactive systems
interrupt-driven systems
signal-driven systems
|
|
| ==> event-driven systems
|
|
29
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.
30
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.
31
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.
32
Sistemi Reattivi (Cont.)
Un sistema real-time è un sistema reattivo che
deve rispettare vincoli temporali (timing
constraints).
• Il termine reactive è più specifico di eventdriven (piuttosto overloaded in letteratura)
• ma è più generale di soft real-time e near realtime: 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).
33
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 eventdriven (piuttosto overloaded in letteratura)
• ma è più generale di soft real-time e near realtime: 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 eventdriven (piuttosto overloaded in letteratura)
• ma è più generale di soft real-time e near realtime: 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