corba - Martin-Luther-Universität Halle

Aufbau Integrierter Informationssysteme
Verteilte Objektsysteme am Beispiel von CORBA
Falk Ritschel, Stefan Springer, Falko Steponat
Martin-Luther-Universität Halle-Wittenberg
Informatikseminar - Halle - 22.01.2002
Gliederung
1. Einleitung
2. CORBA – Architektur (OMG)
3. Kommunikation zwischen den Objekten
4. CORBA in der Praxis
6. Fazit - Ausblick
Verteilte Objektsysteme am Beispiel von CORBA
2
Gliederung
1. Einleitung
Motivation
Grundbegriffe
OMG
Einführung
2. CORBA – Architektur (OMG)
3. Kommunikation zwischen den Objekten
4. CORBA in der Praxis
6. Fazit - Ausblick
Verteilte Objektsysteme am Beispiel von CORBA
3
1. Motivation
• Softwareentwicklung in den letzten 15 Jahren
Einzug des Paradigmas der Objektorientierung
Zunehmende Vernetzung
• Aufteilung von Software in Komponenten
(Objekte)
•Client-Server, Multi-Tier, Internet
•Anwendungen verteilt über Rechner und
Architekturen
• Austauschbarkeit
(wohldefinierte
•Anwendungen
kommunizieren über
Schnittstellen
) und Wiederverwendbarkeit
Middleware
•bessere Administrierbarkeit,
• Schnellere
Implementierung
von Software
Skalierbarkeit,
Ausfallsicherheit,
Investitionsschutz
•Zusammenarbeit heterogener Plattformen
1.
2.
3.
4.
5.
CORBA
4
1. Motivation
Logische Konsequenz:
Vereinigung der Konzepte:
Konkretisierung
diesesin Referenzmodells:
Funktionalität bereitstellen
Form von Komponenten
Verteilung der Komponenten auf beliebige Rechner
ImplementierungCORBA
in unterschiedlichen Sprachen
(Common Object Request Broker Architekture)
Standardarchitektur für verteilte Objektsysteme
OMG (Object Management Group)
Referenzmodell für verteilte Objektsysteme OMA
(Object Management Architecture)
1.
2.
3.
4.
5.
CORBA
5
1. Motivation
Vorteile von verteilten, komponentenbasierten Anwendungen:
Fehlerbehebung durch Austausch einer Komponente
Verteilung der Arbeitslast auf mehrere Systeme
Vorteile der Objektorientierung auch über Prozeß- und
Maschinengrenzen hinaus
Wiederverwendbarkeit von
Komponenten
optimale Strukturierung
1.
2.
3.
4.
5.
CORBA
6
2. Grundbegriffe
• Verteilte Anwendungen
– Bestandteile (Objekte, Komponenten etc.) über mehrere Prozesse
u./o. Computer verteilt
• Heterogene Anwendungen
– Bestandteile befinden sich auf Computern mit verschiedener
Hardware, BS oder Programmiersprache
• übliche OOP-Konzepte
– Kapselung
• Schnittstelle und Implementierung grundsätzlich getrennt
• Schnittstelle wird sprachunabhängig in IDL (Interface Definition
Language) beschrieben
– Vererbung
– Polymorphie
1.
2.
3.
4.
5.
CORBA
7
3. Object Managemant Group
• Die Object Management Group:
1989 als Industriekonsortium gegründet von:
3COM, American Airlines, Canon, Data General, Hewlett Packard, Philips
Telecommunications, Sun Microsystems und Unisys
Ziel: Verbreitung von OO-Technik und verteilter Verarbeitung
Weg: Erarbeiten und Durchsetzen von Industriestandards
Heute weit über 800 Mitglieder!
weitaus größtes Industriekonsortium der IT-Branche
1.
2.
3.
4.
5.
CORBA
8
3. Object Managemant Group
Mitglieder:
– viele Anbieter und Entwickler von Systemen
– Forschungsinstitutionen
– reine Anwender objektorientierter Technologien
– Populärstes Nichtmitglied war jahrelang die Firma
Microsoft
• Distributed Component Object Model (DCOM) - Standard
als Konkurrenz für CORBA
• inzwischen auch passives Mitglied der OMG
– Bekannte Produkte: CORBA und UML
1.
2.
3.
4.
5.
CORBA
9
3. Object Managemant Group
• Die OMG ist kein Gremium zur Standardisierung und kann somit
nicht mit Institutionen wie dem “American National Standards
Institute” (ANSI)
ANSI oder der “International Standards Organisation”
(ISO)
ISO verglichen werden.
Die OMG versteht sich als Organisation, die den Mitgliedern die
Diskussion kontroverser Ansichten, den Austausch
Austausch von
von Ideen,
Ideen
die Suche nach einem Konsens und einer Übereinkunft
bezüglich der Verwendung bestimmter Architekturen und
Technologien erlaubt.
1.
2.
3.
4.
5.
CORBA
10
4. Einführung
Anforderungen an einen Komponentenstandard in heterogenen
Netzen
Programmiersprachenunabhängigkeit
Plattformunabhängigkeit
DerVerschiedene
Client und das
Der
Client
und
das
Serverobjekt
Der Client
muss
nicht
Instanz
zwischen
Client
Datendarstellung
Objekte
verschiedener
Serverobjekt
können
können
auf
durch
wo das
und wissen,
Serverobjekt
passt
in verschiedenen
Hersteller
können
Programmiersprache,
verschiedenen
Serverobjekt
läuft (Lokal,
unterschiedliche
Programmiersprache
zusammenarbeiten
Hardware
undan.
Betriebssystemen
LAN,
WAN,
Internet).
Datenrepräsentation
n geschrieben
sein.
Compiler
vorgegeben
laufen.
Darstellungsunabhängigkeit
Ortsunabhängigkeit
Herstellerunabhängigkeit
(nicht proprietär)
1.
2.
3.
4.
5.
CORBA
11
4. Einführung
Application
Objects
Geschichte von CORBA
Die Geschichte von CORBA ist die Geschichte der OMG:
1989: Gründung der OMG
Anfang 1990: Erste Ergebnisse:
Object Request Broker
Object
Services
• Vorstellung des
Object Management Architecture (OMA) Referenzmodells
• Wichtigster Bestandteil: Object Request Broker (ORB)
Common
Facilities
Anfang 1991: Erste CORBA-Version
•Genauere Spezifikation der ORB Komponente der OMA
•Problem in der Praxis: Mangelnde Interoperabilität
1.
2.
3.
4.
5.
CORBA
12
4. Einführung
Geschichte von CORBA
1992: OMA 2.0
1995: CORBA 2.0
• Interoperabilität zwischen ORBs verschiedener Hersteller
Ende 1995: Spezifikation der erweiterten Dienste
Anfang 2001: CORBA 3.0
• Quality of Service, Unterstützung von Firewalls
• „Spezielle“ CORBAs: Echtzeitanwendungen, Microcontroller, ...
1.
2.
3.
4.
5.
CORBA
13
Gliederung
1. Einleitung
2. CORBA - Architektur (OMG)
Services
Facilities
Domain
Objekte
Applikation
Objekte
3. Kommunikation zwischen Objekten
4. CORBA in der Praxis
5. Zusammenfassung - Fazit - Ausblick
CORBA
14
Object Management Architecture
Gemeinsame
Einrichtungen
(CORBA Facilities)
Domänenschnittstellen
CORBA –
Anwendungen
Common Object Request Broker Architecture
Objektdienste (CORBA Services)
1.
2.
3.
4.
5.
CORBA
16
1. CORBA Services
Weiten die Kernfunktionen von CORBA aus.
Objekte
erzeugen
• Lifecycle
• Persistence
• Transaction
1.
2.
Zugriff auf Objekte
steuern
• Naming
• Trader
• Query
• Events
3.
5.
4.
Beziehungen
zwischen
Objekten
unterhalten
• Security
• Licensing
• Time
CORBA
17
1. CORBA Services
Naming Service
Objekt
A
= damit können Objekte in einer verteilten
Umgebung allein anhand ihres Namens
gefunden werden
Registrierung
Anfrage
Adressierung im Internet:
IP-Adresse Host-Rechner +
TCP/UDP-Portnummer des
Prozesses
1.
2.
3.
4.
Adresse
5.
Objekt
B
CORBA
18
1. CORBA Services
Naming Service
= damit können Objekte in einer verteilten
Umgebung allein anhand ihres Namens
gefunden werden
Ohne diesen Service wäre die Ortstransparenz
nicht gegeben.
 jedes Objekt, dessen Methoden aufgerufen werden sollen, müsste
beim Aufrufer in allen technischen Details bekannt sein
1.
2.
3.
4.
5.
CORBA
19
2. CORBA Facilities
Gruppen von Komponenten die zusätzliche Funktionen bereitstellen.
Funktionen
• sind für anwendungsspezifische Aufgaben wichtig
• z.B. Behandlung des Arbeitsablauf und
Benutzeroberflächen
• zusätzliche Unterstützung der
Anwendungsentwicklung durch Bereitstellung von
Funktionen auf höherer Ebene (E-Mail)
1.
2.
3.
4.
5.
CORBA
20
2. CORBA Facilities
Gruppen von Komponenten die zusätzliche Funktionen bereitstellen.
Horizontal Facilities
Vertical Market Facilities
• User Interface
• Internet Management
• Information
• Computer
Integrated
• Information
Modelling
Manufacturing
• Verteilte Simulation
• Öl und Gas Industrie
1.
2.
3.
4.
• Systems Management
• Finanzwelt
• Task
Management
• Applikations-Entwicklung
• Telekommunikation
• Gesundheitseinrichtungen
5.
CORBA
21
3. Domain Objekte
Stellen Funktionen für die Entwicklung von Anwendungen in
Speziellen Bereichen bereit.
• Medizin, Telekommunikation, Finanzwesen
Bieten Lösungen für immer wiederkehrende Problemstellungen
aus den jeweiligen Bereichen, sind aber zu spezifisch um
sie den CORBA Facilities zuzuordnen.
1.
2.
3.
4.
5.
CORBA
22
4. Applikation Objekte
Gruppen von Objekten oder Komponenten die speziell für
bestimmte Anwendungen entwickelt worden.
= nutzen den den ORB und die weiteren Dienste der CORBA-Architektur
um verteilungstransparent miteinander zu kommunizieren
Verschiedene
Anwendungsprogrammierer
erstellen
1.
2.
Objekte
3.
4.
5.
Verschiedene
Hersteller
verkaufen
CORBA
23
Gliederung
1. Einleitung
2. CORBA – Architektur (OMG)
3. Kommunikation zwischen den Objekten
RPC
ORB
IDL
Kommunikation der Objekte
4. CORBA in der Praxis
6. Fazit - Ausblick
Verteilte Objektsysteme am Beispiel von CORBA
24
Gliederung
•
Kommunikation zwischen den Objekten
•
RPC – Remote Procedure Call
•
ORB – Object Request Broker
•
•
1.
•
Komponenten des ORB
•
Anbieter
IDL Interface Definition Language
•
Einführung
•
Sprachumfang
•
Vorteile einer eigenen Beschreibungssprache
Kommunikation der Objekte
2.
3.
4.
5.
CORBA
25
1. RPC – Remote Procedure Call
• eine verbreitete Abstraktion für die Programmiersprache C
• ermöglicht den Aufruf einer Prozedur auf einem anderen System
• Aufrufschnittstelle der Prozedur ist unabhängig von einer
Programmiersprache
• Schnittstelle wird mit der IDL – Interface Definition Language
beschrieben
•
1.
Prozeduraufruf Transparent zu gestalten
2.
3.
4.
5.
CORBA
26
1. RPC – Remote Procedure Call
Client
Client
Stub
Network
Transport
Portmapper
Server
Stub
Server
1
2
3
4
5,6
7
1.
2.
3.
4.
5.
CORBA
27
2. ORB – Objekt Request Broker
• zentrale Komponente der CORBA Architektur
• verteilte Objekte transparent miteinander kommunizieren zu
lassen
• Server Objekt finden
• Parameter übertragen
• Ergebnis des Methodenaufrufs zurückliefern
•
ORBs müssen auf dem Client und dem Server laufen
•
Kommunikation zwischen den ORBs
• GIIOP
• IIOP
1.
2.
3.
4.
5.
CORBA
28
2. ORB – Object Request Broker
Dynamic
Invocation
Interface
(DII)
Server
IDLDynamische
Server- Skelettskelett schnittstelle
IDLClientstub ORBSchnittstelle
ORB – Kern
1.
2.
ORBSchnittstelle
IIOP/GIOP
3.
4.
5.
Objektadapter
Implement.
Repository.
Interface
Repository.
Client
ORB - Kern
CORBA
29
2. ORB – Object Request Broker
IDL – Clientstub
Dynamic
Invocationvom
Interface
(DII) und
Interface Repository (IFR)
• wird automatisch
IDL – Compiler
erzeugt
••stellt
die Verbindung
zwischen d.h.
Client
und ORB her
dynamischer
Methodenaufruf
Schnittstellen
sind nicht bekannt
ORB
- Schnittstelle
••verpacken
Methodenparameter
in ein über das Netzwerk
eigentlicheder
Basisschnittstelle
zum ORB
• stellt eine Sammlung von Operationen zur Verfügung, die zur
transportierbares
Format
• Interface Repository
enthält Schnittstelleninformationen
Realisierung von Clients notwendig sind
• statischer
Methodenaufruf
d.h.
Schnittstellen
sindRückgabewert
bekannt
• Namen
und Parameter
(Anzahl,
Datentyp),
der
• Zugriff auf die ORB – Schnittstelle auch für den Server möglich
• normale
Anwendungsprogramme
Methoden
• Operationen:
• Service Programme und Utilities
•Object_to_string(), string_to_object()
• create_list(), create_operation_list()
1.
2.
3.
4.
5.
CORBA
30
2. ORB – Object Request Broker
IDL – Serverskelette
Dynamic Skeleton Interface (DSI)
• wird automatisch vom IDL – Compiler erzeugt
ORB – Schnittstelle und Implementation Repository
Gegenstück
zumzum
Dynamic
Invocation
Interface
• •stellt
Verbindung
Objektadapter
und
Serverobjekt her
Object Adapter
•eingehende
ORB – die
Schnittstelle
Analogdynamisch
zur Client beantwortet
Seite
Anfragenist
können
werden d.h. ohne
• •entpackt
Methodenparameter
von
OMGalle
wird
ein Basic
Object Adapter (BOA) spezifiziert
• •verwaltet
Server
Objekte
Spezifizierung
• IDL
ruft
die Methoden
im Serverobjekt
auf
•wird
ist Verbindungsglied
zwischen
ORB
und
Serverobjekt
genutzt
wenn noch
keine
Instanz
eines Server Objektes
• •nutzt
die
Informationen
die
vomkorrekte
DII
kommen
• Registrierung von Objektimplementierungen (Server)
existiert
• Server- Aktivierung und – Deaktivierung
• Erzeugen von Objektreferenzen für Implementierungen
• Authentisierung und Zugriffskontrolle
• verantwortlich für die persistente Gültigkeit von Objektreferenzen
1.
2.
3.
4.
5.
CORBA
31
2. ORB – Object Request Broker
ORB - Kern
GIOP – General Inter ORB Protocol
• ist verantwortlich für die Kommunikation
IIOP – Internet Inter ORB Protocol
basiert aufdie
dem
Pyrotechnic
Longitudinal ORB Protocol
• •beinhaltet
gesamte
Infrastruktur
basiert
auf
dem
GIOP Kommunikation
• •ist
für zu
jede
CORBA
•Basis
Objekte
identifizieren
und zu lokalisieren
Kommunikation
inzuTCP/IP
Netzwerke
• •existiert
seit CORBA
2.0
• Verbindungen
verwalten
ORBs
müssen
IIOP unterstützen um CORBA konform zu sein
• •ist
•netzwerkneutral
Daten
zu übermitteln
1.
2.
3.
4.
5.
CORBA
32
2. ORB – Object Request Broker
ORB - Anbieter
MICO
http://www.mico.org
NEO und Joe: Sun Microsystems
http://www.sun.com/sunsoft/neo
ORBacus: Object-Oriented Concepts, Inc
http://www.orbacus.com
Orbix: IONA
http://www.iona.com
SOM: IBM
http://www.software.ibm.com/objects/
somobjects
VisiBroker: Visigenic
1.
2.
http://www.visigenic.com/prod/
3.
4.
5.
CORBA
33
3. IDL – Interface Definition Language
IDL – Interface Definition Language
IDL – Compiler
• ist die genormte Basis zur programmiersprachenunabhängigen
C IDL – Schnittstellenbeschreibung C
•CÜbersetzungvon
der
Beschreibung
Objektschnittstellen
Skeleton
Stub
C
• Schnittstelle = alle
C++ eines Objektes
C++ exportierten Attribute und Methoden
C++
IDLSyntax
- Datei
• orientiert sich an der C++
Skeleton
Java
Java
• wichtiger Bestandteil ist der IDL- Compiler
Java
Skeleton
Smaltalk
Stub
IDL - Compiler
IDL - Stub
ADA
COBOL
1.
2.
Server
Smaltalk
ORB
Stub
Client
Stub
Smaltalk
Skeleton
C++
Java
Smaltalk
IDL - Skeleton
ADA
Stub
ADA
Skeleton
ADA
COBOL
Stub
COBOL
Skeleton
COBOL
3.
4.
5.
CORBA
34
3. IDL – Interface Definition Language
Datentyp
Beschreibung
Java Mapping (Wert)
C++ Mapping (Wert)
Short
Long
long long
unsigned short
unsigned long
unsigned long long
Float
double
long double
Char
Wchar
boolean
Octet
string
wstring
Any
16 bit Integer
32 bit Integer
64 bit Integer
16 bit vorzeichenlos
32 bit vorzeichenlos
64 bit vorzeichenlos
16 bit IEEE Gleitkomma
32 bit IEEE Gleitkomma
64 bit IEEE Gleitkomma
8 bit Zeichen
16 bit Zeichen (Unicode)
TRUE oder FALSE
einzelnes Byte
Zeichenkette
Zeichenkette (Unicode)
Container für einen
beliebigen Datentyp
short
int
long
short
int
long
float
double
double
char
char
boolean
byte
java.lang.String
java.lang.String
?
CORBA::Short
CORBA::Long
CORBA::LongLong
CORBA::UShort
CORBA::ULong
CORBA::ULongLong
CORBA::Float
CORBA::Double
CORBA::LongDouble
CORBA::Char
CORBA::WChar
CORBA::Boolean
CORBA::Octet
CORBA::String
CORBA::WString
CORBA::Any
1.
2.
3.
4.
5.
CORBA
35
3. IDL – Interface Definition Language
Bezeichner
Module
• Zulässig sind beliebig lange Zeichenketten
Interfaces
• erzeugen
einen neuen
Namensraum,
um Namenskonflikte zu vermeiden
• nicht identisch
zu einem
IDL – Schlüsselwort
Operationen
deklariert diemit
Daten
und
Operationen
eines Objektes
• •vergleichbar
einem
Packages
bei Java
• beginnt mit einem
Buchstaben
Attribute
•entspricht
eine Aktion
die
an
einem<Modulname>
Objekt durchgeführt
einer
bei Java oderwird
C++
• •Schlüsselwort
ist Klassendefinition
module
• kann Buchstaben,
Ziffern und Unterstriche enthalten
•entspricht
Attribute
sind
vergleichbar
mit nicht
Variablen
einer
Elementefunktion
beiimplementiert
C++ oder einer Methode bei Java
• •Attribute
und
Methoden
werden
• ist innerhalb eines Namensraum eindeutig
•Rückgabetyp,
nach demistcompilieren
existieren get und set Methoden
Identifizierer
• •Vererbung
möglich
•Null
optionales
Schlüsselwort
readonly
oder mehrere
Parameter
(in, out, inout)
• •Schlüsselwort
ist interface
<Interfacename>
Schlüsselwort:
readonly
attribute
<Attributsname>
• •Optionales
raisesSchlüsslewort
fürDatentyp
Exceptions
• Schlüsselwort ist Rückgabewert Operationsname <Parameter> raises
1.
2.
3.
4.
5.
CORBA
36
3. IDL – Interface Definition Language
module Bank1 {
// Deklaration einer eigenen Exception
exception BankFehler {
string info;
};
interface IKonto1 {
readonly attribute long nummer;
double einzahlen (in double betrag) raises (BankFehler);
};
// IGiroKonto erbt von IKonto1
interface IGiroKonto : IKonto1 {
double leseKreditLimit();
};
interface ISparKonto : IKonto1 {
double leseZinssatz();
};
// IGiroKonto erbt von ISparKonto und IGiroKonto
interface IGiroSparKonto : ISparKonto, IGiroKonto {
};
};
1.
2.
3.
4.
5.
CORBA
37
3. IDL – Interface Definition Language
• Vorteile einer eigenen Beschreibungssprache
• maschinelle Weiterverarbeitung
• unabhängig von Programmiersprachen
• Isolierung Systemspezifischer Eigenschaften
1.
2.
3.
4.
5.
CORBA
38
4. Kommunikation der Objekte
Client X ruft
Methode M von Y
auf
Objekt Y
Methode M
Object Request Broker (Core)
1.
2.
3.
4.
5.
CORBA
39
4. Kommunikation der Objekte
Client Anwendung
Server Anwendung
Auspacken und
Aufrufen
Aufruf
IDL - Stub
Aktivieren
IDL - Skeleton
Weiterleiten an
Schnittstelle
Parameter
einpacken und
weiterleiten
Objektadapter
Transport über den ORB
Implementation
Repository
Ermitteln der
Implementierung
Object Request Broker
1.
2.
3.
4.
5.
CORBA
40
Gliederung
1. Einleitung
2. Konzeptionelle Architekturen
3. Wege zu integrierten Datenbanksystemen
4. CORBA in der Praxis
Vorgehensmodell
Beispielanwendung
5. Zusammenfassung - Fazit - Ausblick
Verteilte Objektsysteme am Beispiel von CORBA
41
Gliederung
• CORBA in der Praxis
• Vorgehensmodell
• Beispielanwendung
• IDL - Dokumente
• IDL – Stub, IDL – Client
• Java Server
• Java Client
1.
2.
3.
4.
5.
CORBA
42
Kundenauftrag
Problemanalyse uns Systemdesign
Entwicklung der IDL- Beschreibung
IDLDokumente
Client
Implemt.
IDLStubs
IDLSkeleton
Java
Compiler
Server
Implemen.
C++
Compiler
Kommunikation
Client
Server
2. Beispielanwendung
IDL - Datei
// Keine Parameterübergabe
module Beispiel01
{
interface Hello
{
// aber einen String als Returnwert
String sagHallo();
};
};
1.
2.
3.
4.
5.
CORBA
44
2. Beispielanwendung
Java - Files
• Hello.java
• _HelloStub.java (der Clientstub)
• _HelloImplBase.java (das Server - Skeleton)
• HelloHelper.java (einer Helper Klasse)
• HelloHolder.java (eine Holder Klasse)
1.
2.
3.
4.
5.
CORBA
45
2. Beispielanwendung
Java - Interface
//Package Definition
package Beispiel01;
//Interface Definition
public interface Hello extends org.omg.CORBA.Object,
org.omg.CORBA.portable.IDLEntity{
//Metoden Definition
String sagHallo();
}
1.
2.
3.
4.
5.
CORBA
46
//Package Definition
package Beispiel01;
//Import Anweisungen
import org.omg.CosNaming.*;
import org.omg.CosNaming.NamingContextPackage.*;
import org.omg.Corba.*;
import java.lang.*;
//Class Definition
public class HelloServer{
//Metoden Definition
public static void main(String[] args){
try{
CORBA – Server - Objekt
//Initialisierung des ORB
anmelden
ORB orb = ORB.init(args,null);
HelloImpl hi = new helloImpl();
orb.connect(hi);
org.omg.CORBA.Object objRef = orb.resolve_initial_references(“NamingService“;)
NamingContext ncRef = NamingContextHelper.narrow(ObjRef);
NameComponent nc = new NameComponent(“Hello“, ““)
NameComponent path[] = {nc};
Interaktion mit
ncRef.rebind (path, hi;)
dem Name Server
Object sync = new Object();
NamingContext
vorbereiten
synchronized (sync)
Objekt den
{
richtigen
sync.wait();
}
Anbindung am
Datentypen
}//Ende try
Name Server
zuweisen
catch(exception e){
(Objekte, Name)
System.out.println(“Fehler“);
e.exceptionStackTrace();
}
}//Ende main()
}
2. Beispielanwendung
Java - Server
//Die Methode die der Client aufruft
public String sagHallo(){
System.out.println(“HelloImpl: sagHallo: return Hallo“);
return Hallo;
}
1.
2.
3.
4.
5.
CORBA
48
Java - Client
//Package Definition
package Beispiel01;
//Import Anweisungen
import org.omg.CosNaming.*;
import org.omg.CosNaming.NamingContextPackage.*;
import org.omg.Corba.*;
import java.lang.*;
//Class Definition
public class HelloClient{
//Globale Variable
static Hello hi = null;
//Metoden Definition
public static void main(String[] args){
try{
//Initialisierung des ORB
ORB orb = ORB.init(args,null);
org.omg.CORBA.Object objRef = orb.resolve_initial_references(“NamingService“;)
NamingContext ncRef = NamingContextHelper.narrow(ObjRef);
NameComponent nc = new NameComponent(“Hello“, ““)
NameComponent path[] = {nc};
org.omg.CORBA.Object o = ncRef.resolve((path);
hi = HelloHelper.narrow(o);
}//Ende try
catch(exception e){
System.out.println(“Fehler“);
e.exceptionStackTrace();
Objektreferenz
}
Aufruf der Server
//Rufe Methode am Server auf
vom Name Server
System.out.println(hi.sagHallo)
Methode
gewonnen
}//Ende main()
}//Ende class HelloClient
NamingContext
Objekt den
richtigen
Datentypen
zuweisen
Gliederung
1. Einleitung
2. CORBA – Architektur (OMG)
3. Wege zu integrierten Datenbanksystemen
4. CORBA in der Praxis
5. Zusammenfassung - Fazit - Ausblick
Vorteile - Nachteile
Ausblick
Zusammenfassung
Verteilte Objektsysteme am Beispiel von CORBA
50
1. Vorteile und Nachteile
– Vorteile
• Ist vergleichsweise einfach
• Die wichtigsten Sprachen können eingesetzt werden
• Transparenz (Ort, Verteilung)
• Statische und dynamische Aufrufe
• Unabhängig von einer Programmiersprache
• Vordefinierte Dienste
• Trennung von Schnittstelle und Implementierung
•Nachteile
• Geringe Performance, insbesondere auf lokalem Rechner
• Interoperabilität verschiedener ORBs in der Praxis nicht sicher
gewährleistet
• Geringe Bedeutung unter MS Windows
1.
2.
3.
4.
5.
CORBA
51
2. Ausblick
– durch neue Komponentenmodelle in die Defensive gedrängt
• Enterprise Java Beans (EJB) des J2EE Frameworks
• COM+ des .NET Framework
• Web – Services (SOAP, WDSL, XML)
– Ziel Brücken zwischen CORBA und neuen Technologien
1.
2.
3.
4.
5.
CORBA
52
3. Zusammenfassung
– OMG
– Geschichte CORBA
– CORBA Komponenten
– ORB - Objekt Request Broker
– IDL - Interface Definition Language
– CORBA Kommunikation
1.
2.
3.
4.
5.
CORBA
53