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

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

• 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 gt 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).