Seminar VA (03/04) 1T.S. (JD)
Verteilte Anwendungen Seminar
17.01.2004
Seminar VA (03/04) 2T.S. (JD)
Wiederholungletzte Veranstaltung
● Client/Server-Modell● Socket-Programmierung
– Kommunikationsbereich
– 5er-Tupel zur Spezifikation
– Einfaches Python-Beispiel
– Java™-Beispiel mit Exception-Handling
Seminar VA (03/04) 3T.S. (JD)
Lernziele
Verteilte Anwendungen● Grundlagen zu VA● Entwicklungsumgebungen und RE‘s
– Remote Procedure Call
– Java™ Remote Method Invocation● Einstieg in Middleware
– CORBA
Seminar VA (03/04) 4T.S. (JD)
Was sind verteilte Anwendungen?(Modelle)
Hardware
Betriebssystem
Plattformen für verteilte AnwendungenMiddleware
(Verteilte Systeme)
Verteilte Anwendungen
physical
Data link
network
transport
session
presentation
application
Networkinterface
internet
transport
application
ISO/OSITCP/IP
UI
App.-protokolle
App
DB
NetzwerkProtokolle
3-Tier
Seminar VA (03/04) 5T.S. (JD)
Architekturmodelle verteilter Anwendungen
Internet
Client/ServerPeer-to-Peer
RZ
RZ
Cluster/Grids
mgr.
Client
qmast.Internet
execD
Server
Kunden
InternetcomputingVerteiltes Rechnen
Seminar VA (03/04) 6T.S. (JD)
Anwendungsfelder verteilter Anwendungen
VA
Webapps
EAI
Portale
Marktplätze
Online-BankingOnline-Buchung
SCM BackofficeInformations-
Kooperationssysteme
Ressourcen-anbindung
Steuern, Messen, Regeln
DB-Anbindung
Flugbuchung
GeldautomatenJ2EE
Konnektoren
„.NET“
Plattformen
CORBASOAP
„Agentensysteme“
VerteilteSysteme
DSM
Vert.Filesysteme
Vert.BS
#Cruncher/Cluster
P2P-Computing
Meta-/ Distributed-/Internet-Computing
Seminar VA (03/04) 7T.S. (JD)
Was wird verteilt?
● Hardwareressourcen Zugriff aufs Arecibo Space Laboratory
● Daten Zugriff auf Inhalte anderer Leute (WWW!)
● Last Zu viele Anfragen für einen Web-/ DB-Server
● Verarbeitung Cluster und Grids
● Kontrolle Verteiltes Betriebssystem
Seminar VA (03/04) 8T.S. (JD)
Verteilte Anwendungen
Eine verteilte Anwendung besteht aus mehreren nebenläufigen, untereinander kommunizierenden Prozessen, die gemeinsam die Leistung der verteilten Anwendung erbringen.
Was ist der Unterschied zu verteilten Systemen? Ein verteiltes System ist ein System, dessen Daten und dessen
Funktionskomponenten auf mehrere, zu einem Netz zusammengeschlossene Rechner verteilt sind.
Also:
Bei verteilten Systemen bezieht sich die Verteilung in der Regel auf die Funktionalität unterhalb der Anwendung!
Seminar VA (03/04) 9T.S. (JD)
Aufgaben, Anforderungen und Ziele verteilter Anwendungen
● Aufgaben: Dezentralisierung von Programmsystemen– Dezentralisierung der Datenverwaltung– Dezentrale Verarbeitung von Daten
– Entfernter Zugriff auf Daten– Entfernter Eingriff auf die Datenverarbeitung– Unterstützung der Anwenderkommunikation
● Anforderungen:
– Zuverlässigkeit
– Geschwindigkeit– Transparenz– Sicherheit
● Ziele:
– Ressourcen-Sharing– Informations-Sharing
Verteilte Anwendungen stellen auf Basis der Netzwerke spezielle Dienste bereit
Seminar VA (03/04) 10T.S. (JD)
Problematik verteilter Anwendungen
VA zeichnen sich durch sehr hohe Komplexität aus:
• Systemumfang
• Heterogene Teilsysteme
• Kommunikation über das Netzwerk
- Ausfall des Netzes
- Fehler bei der Übertragung
- Adressierung
Seminar VA (03/04) 11T.S. (JD)
Herausforderungen für verteilte Anwendungen
• Transparenz
• Interoperabilität
• Fehlerbehandlung
• Datenschutz und Datensicherheit
• Parallelität
• Skalierbarkeit
• Offenheit
• Systemumfang
• Administration
Seminar VA (03/04) 12T.S. (JD)
Mittel zur Lösung Netzwerktransparenz
Die Kommunikation über das Netzwerk birgt Probleme, von denen abstrahiert werden soll:
● Fehleranfälligkeit:
– Erkennung, Übertragungswiederholung, Reihenfolgegenauigkeit etc. TCP
● Adressauflösung/ Ortstransparenz
– Host-/ Prozessadresse auflösen, Migration und Replikation erlauben Namens- und Lokalisierungsdienste
● Zugriffstransparenz
– Programmierung als gäbe es keine örtliche Trennung lokale Proxyobjekte
Seminar VA (03/04) 13T.S. (JD)
Mittel zur LösungKommunikation, Interoperabilität
● Kommunikationsmechanismen:
– IPC
– RPC
– RMI
● Interoperabilität: Verbindung heterogener Einzelsysteme bedarf:
– Standardisierter Protokolle
– Externer Datendarstellung (XDR, CDR)
– Normierter Schnittstellen
Seminar VA (03/04) 14T.S. (JD)
Erinnerung:Client/Server-Modell
(Internet)
Seminar VA (03/04) 15T.S. (JD)
Kommunikations-Modell zwischen Client und Server(Erinnerung)
● Die Kommunikation erfolgt in Form von Frage-Antwort-Paaren.● Es besteht eine asymmetrische Kommunikationsbeziehung, die sich im
Prozeßkonzept widerspiegelt.
a) Der Client schickt eine Anforderung (Request) an einen Server.
b) Der Server behandelt die Anforderung und schickt eine Antwort (Response) mit Ergebnis.
Client
Request
Server
Response
Asymmetrie auch in der Kommunikationsform:Der Client überliefert asynchron (zu einem beliebigen Zeitpunkt) eine Anforderung an einen Server.Der Server antwortet synchron (in einem bestimmten Zeitintervall).
Seminar VA (03/04) 16T.S. (JD)
Erinnerung: Socket – API
● Ein Socket ist ein Kommunikationsendpunkt innerhalb eines Kommunikationsbereiches.
● Ein Datenaustausch erfolgt zwischen zwei Sockets● Die Verbindung zwischen zwei Sockets ist durch ein Socket-Paar
gekennzeichnet.● Eine Socket-Kommunikationsbeziehung ist immer durch folgendes
Fünfertupel definiert: (protocol, local-addr, local-process, foreign-addr, foreign-process)
Wunsch nach höherer Abstraktion von der Netzprogrammierung und nach Transparenz der Datendarstellung
Seminar VA (03/04) 17T.S. (JD)
Remote Procedure Call
● Erweiterung des Prozeduraufruf-Mechanismus von Einzel-Rechnern auf verteilte Bearbeitungsumgebungen
● Der Server bietet ein oder mehrere Interface(s) für die Anforderung seiner Dienste (in Form von entfernten Prozeduraufrufen) an.
● Kapselung von Client-Requests in einfache (entfernte) Prozeduraufrufe● Für den Programmierer ist nur ein geringer Anteil Netzprogrammierung
erforderlich, im Vordergrund steht die Gestaltung der Client/Server-Anwendung.
Unterstützung durch RPC-Laufzeitsystem– die Umwandlung/Übersetzung von auszutauschenden Parametern zwischen
verteilten (heterogenen) Komponenten übernimmt,
– Transferdienstbesonderheiten vor der Anwendung verdeckt (z.B. Timeouts und Retransmission)
Seminar VA (03/04) 18T.S. (JD)
Interprozesskommunikation:lokal
Client Procedures
Interface
Call
Return
Client
Client Stub
Client Process
CallReturn
RPC Runtime Library
Manager
Server Stub
Server Process
ReturnCall
RPC Runtime LibraryNetwork Messages
Interface
verteilt
Seminar VA (03/04) 19T.S. (JD)
Ablauf eines RPC
Client-Stub
Client-Routinen
RPC-Laufzeitsystem
(1)
(2) (9)
(10)
Server-Stub
Server-Routinen
RPC-Laufzeitsystem
(6)
(7) (4)
(5)
(3)
(8)
Seminar VA (03/04) 20T.S. (JD)
RPC/RMI-Entwicklungsprozess (allgemein)
RPC-Spezifikationsdatei
RPC-Generator/Compiler
Client-Routinen
Server-Routinen
Server-StubHeaderClient-Stub
Header HeaderClient-Stub Server-Stub
Compiler Compiler
Client-Objektdateien
Server-Objektdateien
Client-Stub(Objekt)
Server-Stub(Objekt)
RPC-Bibliothek
RPC-Bibliothek
Linker Linker
Client Server
Seminar VA (03/04) 21T.S. (JD)
Distributed Computing EnvironmentDCE
● Für RPC wird Laufzeitumgebung benötigt.● „The Open Group“ (Open Software Foundation) DCE
– Tools und Services zur Unterstützung, Nutzung und Wartung verteilter Anwendungen in heterogenen Rechnerumgebungen:
Vereinfachung der Entwicklung und des Managements durch Tools Skalierbarkeit durch Zellenkonzept Struktur: übersichtliches Modell und Zugang zu globalem Computing
Env. Portabilität und Interoperabilität (Umsetzung für viele Plattformen!)
Data Sharing zwischen allen Nutzern Integraler Bestandteil vieler BS und „Mutter aller Middleware“
Aber: aus marktpolitischen Gründen hat sich DCE nicht durchgesetzt, ist allerdings Vorbild für viele folgende Systeme verteilter Anwendungen.
Seminar VA (03/04) 22T.S. (JD)
DCE - Architektur
Anwendungen
DCE DisklessSupport Service
ZukünftigeDienste
DCE Distributed File Service
DCEDistributed
Time Service
DCEDirectoryService
ZukünftigeDienste
DCE Remote Procedure Call
DCE Threads
DCESecurityService
Management
Betriebssystem und Transferdienste
Seminar VA (03/04) 23T.S. (JD)
Anwendungsentwicklung mit dem DCE-RPC
UUID Generator Editor
IDL File
ClientStub Header
IDL Compiler
Client File
Editor
C-Compiler
RPCLibrary
Linker
Client
Header
ServerStub
ClientStub
ClientObject
Server Files
Editor
C-Compiler
RPCLibrary
Linker
Server
Header
ServerStub
ServerObjects
Seminar VA (03/04) 24T.S. (JD)
A Simple Interface Definition
/* FILE NAME: arithmetic.idl *//* This Interface Definition Language file represents *//* a basic procedure that remote procedure call can use */[uuid(C985A380-255B-11C9-A50B-08002B0ECEF1),version(1.0)]interface arithmetic /* interface name */{ const long ARRAY_SIZE = 10;
typedef long long_array[ARRAY_SIZE];
void sum_arrays( [in] long_array a, [in] long_array b, [out] long_array c );}
Seminar VA (03/04) 25T.S. (JD)
Binding
Client
Knoten A
Knoten Z
Cell DirectoryServer
Knoten X
RPCDaemon
Port y
„Server?“
„Am Knoten X“
„Server?“
„AmPort y“
„Request“
Server
Anmelden
Server
Port *
* well known
Seminar VA (03/04) 26T.S. (JD)
RPC-Laufzeitprozess
Client
2. AufrufProzedur
15. EntgegennahmeErgebnis
Client Stub 4. VerpackenAufruf nachRPC-Protokoll
3. FindenServer über CDSund RPC-Daemon
14. EntpackenDaten nachRPC-Protokoll
RPC Runtime
5. ÜbertragungDaten zuPartner-RPC-Runtime-Instanz
13. Warten undEntgegennahmevon Daten fürClient
Server 9. AusführenProzedur
8. ÜbernahmeProzeduranforderung
Server Stub 11. VerpackenErgebnis nachRPC-Protokoll
1. AnmeldenServer bei CDSund RPC-Daemon
7. EntpackenDaten nachRPC-Protokoll
RPC Runtime
12. ÜbertragungDaten zuPartner-RPC-Runtime-Instanz
6. Warten undEntgegennahmevon Daten fürServer
10. ÜbergabeErgebnis
Seminar VA (03/04) 27T.S. (JD)
Zusammenfassung(DCE)
● Kommunikation auf der Basis interagierender Prozesse● transparente Interoperabilität in heterogener Umgebung● gute Skalierbarkeit durch das Cell-Konzept und die Implementierung einzelner
Dienste, wie zum Beispiel Cell (Global) Directory Service● zahlreiche Werkzeuge und Dienste, beispielsweise ein konzeptionell ausgefeilter
und umfangreich implementierter Security Service● Ortstransparenz durch Cell Directory Service● Lösungen für die Einbindung von Legacy Systems, zum Beispiel über die
Integration traditioneller Transaktionsmonitore, wie CICS● Programmierung: Anlehnung an C (mit anderen Sprachen aber auch möglich!)
Aber: CORBA hat im Bereich der standardisierten Plattformen für offene verteilte Systeme und Anwendungen eine größere Verbreitung gefunden und SOAP verdrängt zur Zeit langsam aber sicher CORBA
Seminar VA (03/04) 28T.S. (JD)
Remote Method Invocation (RMI)
● Remote Method Invocation entspricht dem RPC in Java● Der Client einer Distributed Object Application arbeitet mit Referenzen auf
entfernte Objekte. (Stubs!)● RMI führt eine strenge Trennung in Interface und Klassen ein ● Lokalisierung entfernter Objekte auf zwei Wegen:
– RMI naming service
– Rückgabe eines Methodenaufrufs
● Die Kommunikation zwischen Client und Server stellen Surrogate-Objekte (Stubs und Skeletons) sicher.
● RMI benutzt Object Serialization für das „Einpacken“ (Marshal) und die Übergabe bzw. das „Auspacken“ (Unmarshal) der Parameter.
Seminar VA (03/04) 29T.S. (JD)
Stubs, Parameterübergabe, Exception Handling
● Der Client kommuniziert mit dem Server-Stub (Proxy), der die gleichen Interfaces wie der zugehörige Server zur Verfügung stellt.
● Stubs werden über das Werkzeug rmic generiert.● Als Parameter oder Rückgabewerte kommen alle Werte beziehungsweise
Objekte in Frage, die serialisierbar sind. Darunter fallen alle Basis-Datentypen sowie Objekte, die das Interface java.io.Serializable implementieren.
● Der Client muß Vorkehrungen zum Abfangen der java.rmi.RemoteException treffen.
Seminar VA (03/04) 30T.S. (JD)
RMI-System-Architektur
● Stubs und Skeltons: Abbildung der Objektreferenzen, Marshal● Remote Reference Layer: Semantik der Methodenaufrufe, zum Beispiel ein
Objekt oder mehrere Verbindungen, ständig laufender Server oder zu startender Server
● Transport Layer: Management der Verbindung
Client
Stub
Remote Reference Layer
Transport
Remote Object
Skeleton
Remote Reference Layer
Transport
Seminar VA (03/04) 31T.S. (JD)
Lokalisierung von entfernten Objekten
● Eine entfernte Objektreferenz kann mit Hilfe von URL-basierten Methoden der Klasse java.rmi.Naming verwaltet werden.
● Das RMI-System stellt einen einfachen Name Server zur Ermittlung von Objektreferenzen auf einer Maschine bereit.
● Beispiel:String url = "//einstein:8329/HelloServer";try { HelloImpl obj = new HelloImpl(); java.rmi.Naming.rebind(url, obj);} catch (Exception e) {...}
String url = "//einstein:8329/HelloServer";try { Hello objRef = (Hello)java.rmi.Naming.lookup(url);} catch (Exception e) {...}
Server
Client
Seminar VA (03/04) 32T.S. (JD)
Sicherheitsmechanismen für den entfernten Zugriff
Für die Nutzung von RMI muss ein Security Manager vorhanden sein.
Zum Beispiel:
if (System.getSecurityManager() == null) { System.setSecurityManager(new RMISecurityManager());}
Ab JDK 1.2 müssen in einem Security Policy File die Rechte für den Zugriff auf Ressourcen vereinbart werden.Zum Beispiel:
grant { permission java.net.SocketPermission “*:1024-65535“, “connect, accept“; permission java.net.SocketPermission “*:80“, “connect“;};
Seminar VA (03/04) 33T.S. (JD)
RMI: Entwicklungsprozeß
i. Design und Implementierung der verteilten Applikation- Definition des Remote Interface- Implementierung der Remote Object Class- Implementierung des Client
ii. Übersetzen der Quellen (javac) und Generieren von Stubs und Skeletons (rmic)
iii. Start der Applikation inklusive Registry, Server und Client
Seminar VA (03/04) 34T.S. (JD)
Remote Interface
● Jedes Remote Interface erweitert das Interface java.rmi.Remote.● Jede entfernte Methode muß die Exception
java.rmi.RemoteException im throws-Statement deklarieren. Diese wird generiert, wenn der Aufruf einer entfernten Methode fehlschlägt.
● Jedes entfernte Objekt, das als Parameter oder Rückgabewert übergeben wird, muß als das Remote Interface deklariert werden, nicht als die Implementierungsklasse.
public interface Hello extends java.rmi.Remote {
String sayHelloTo(String me) throws java.rmi.RemoteException;}
Seminar VA (03/04) 35T.S. (JD)
Implementierung eines Interface
● Eine Klasse zur Implementierung eines Remote Interface erweitert in der Regel java.rmi.server.UnicastRemoteObject und erbt dabei von der Klasse java.rmi.server.RemoteObject und java.rmi.server.RemoteServer.
● Eine Klasse, die ein Remote Interface implementiert kann
– mehrerer Interfaces implementieren und eine andere Klasse erweitern, die ein Remote Interface implementiert,
– Methoden implementieren, die nicht Bestandteil eines Remote Interface sind (diese sind aber nur lokal verfügbar),
– von einer anderen Klasse als Remote Object abgeleitet werden, muß dann aber für die Methoden hashCode, equals und toString die entfernte Semantik implementieren.
Seminar VA (03/04) 36T.S. (JD)
Implementierung eines Interface: Beispiel
import java.rmi.RemoteException;import java.rmi.server.UnicastRemoteObject;
public class HelloImpl extends UnicastRemoteObject implements Hello {
public HelloImpl() throws RemoteException { super(); }
public String sayHelloTo(String you) throws RemoteException {
return(“Hello “ + you + “!“); } ...}
Seminar VA (03/04) 37T.S. (JD)
... und nun an die Arbeit!
Nicht vergessen, es darf gefragt werden! ;-)
Seminar VA (03/04) 38T.S. (JD)
CORBA:Common Object Request Broker Architecture
Middleware-Architektur-Spezifikation der Object Management Group (OMG)
Überblick:● Die Object Management Group (OMG)● Das Objektmodell der OMG● Die Object Management Architecture (OMA)● Die ORB - Architektur (CORBA)● Das CORBA Component Modell (CCM)● Der Implementierungsablauf
Seminar VA (03/04) 39T.S. (JD)
Interoperabilität?
„There will never be consensus on hardware plattforms;
there will never be consensus on operating systems;there will never be consensus on network protocols;there will never be consensus on application formats,
so there must be consensus on interoperability!”
● Zur verteilten Nutzung von Ressourcen und Daten ist eine Interoperabilität auf höherer Ebene unabdingbar.
● Um diese zu erreichen bedarf es einer gemeinsamen Plattform, einer Middleware
● Als Middleware dient bei der OMA der Object Request Broker
Seminar VA (03/04) 40T.S. (JD)
CORBA – die Idee
„Die Vision der Object Management Group ist eine Gesamtarchitektur zu erstellen, in der verschiedene Softwarekomponenten möglichst transparent und in heterogener Umgebung miteinander kommunizieren können.“
● CORBA ist eine Spezifikation der OMG für eine Middleware-Architektur
● Daraus entstand eine objektorientierte Umgebung zur Entwicklung und Unterstützung verteilter Anwendungen
● Erste Spezifikation 10/91, erste Vollimplementierung 7/93● Zur Zeit aktuell: CORBA 3.0 (die meisten Produkte impl. CORBA
2.3)
Seminar VA (03/04) 41T.S. (JD)
Die Object Management Group
● Die OMG wurde 4/1989 von 13 Mitgliedern gegründet.
Ziel der OMG war in erster Linie die Effektivierung des Software-Entwicklungsprozesses und hierbei insbesondere die Unterstützung von Portabilität, Wiederverwendbarkeit und Interoperabilität.
● Aktuell über 800 Mitglieder (Firmen aus der Industrie und Universitäten), davon über 100 „Corporate Members“
Seminar VA (03/04) 42T.S. (JD)
CORBA – technische Ziele
Parallel zu den ideellen Zielen treten eine Reihe technischer Ziele auf:- Ortstransparenz- Gutes Antwortverhalten für lokale wie entfernte Aufrufe- Die dynamische Evolution von Objekten- Zugriff auch über Objektattribute/ Objektbeziehungen (nicht nur Name)
- Parallelisierung (Nebenläufigkeit bei Anfragen durch mehrere Clients)
Es soll also- Ein gemeinsames Referenzmodell für die objektorientierte Software-
entwicklung in heterogenen verteilten Umgebungen bereitgestellt werden, um
- dadurch kompatible technologische Plattformen zu erhalten und so- mit gemeinsamen Protokollen auf gemeinsame Schnittstellen
zugreifen zu können.
Seminar VA (03/04) 43T.S. (JD)
Problem der Komplexität
● Um die Komplexität bewältigen zu können Einführung der OMA:
• Abbildung realer Objekte und Dienstleistungen auf Software-Objekte
• Ein CORBA-Objekt ist eine gekapselte Einheit (Daten und Methoden), welche über eine wohldefinierten Schnittstelle angesprochen wird.
Aber: ein CORBA-Objekt muss nicht objektorientiert erstellt sein, monolithische Systeme können gekapselt als CORBA-Objekte eingesetzt werden
Seminar VA (03/04) 44T.S. (JD)
Objektmodell der OMG
● Orientierung an klassischer OO Aufgrund der Eigenschaften der OO vereinfachte Entwicklung:
- Kapselung (ADT-Paradigma): ADT hat eine sichtbare Schnittstelle und verbirgt seine Implementierung Wiederverwendbarkeit, Lokalität von Änderungen
- Vererbung: zuverlässiger, sicherer und ökonomischer als erneute Erstellung
- Kommunikation über Botschaften: Aufrufsemantik lokale und verteilt gleich
Ein CORBA-Objekt ist eine identifizierbare gekapselte Instanz, welche über ein beziehungsweise mehrere Interface(s) Dienste anbietet
Alle CORBA-Objekte („verteilte Objekte“) können als Dienstnutzer oder Diensterbringer auftreten Client/Server-Modell (bei jeder Kommunikationsbeziehung gibt es einen Client und einen Server)
Seminar VA (03/04) 45T.S. (JD)
CORBA – Client/Implementierung/Server
● CORBA-Clients sind CORBA-Objekte welche Operationen auf anderen Objekten aufrufen und ausführen.
● Objekt-Implementierungen sind CORBA-Objekte welche auf einem CORBA-Server residieren und deren Methoden nach eine Anforderung ausgeführt werden können.
● CORBA-Server sind Software-Komponenten in denen Objekt-Implementierungen residieren und deren Methoden ausgeführt werden können (Container/RE-Semantik)
Seminar VA (03/04) 46T.S. (JD)
CORBA-ObjekteBegriffe
● Request
– ein Ereignis, das zu einem beliebigen Zeitpunkt auftreten kann und dessen Informationen ein Zielobjekt, eine Operation und bei Bedarf Parameter und gegebenenfalls einen Request Context enthalten
– Gefordert wird die Ausführung eines Dienstes für einen Client.
– Requestparameter sind durch ihre Position identifiziert.● Interface
– beschreibt die von einem Objekt über einen Zugangspunkt angebotenen Operationen, die von den Clients genutzt werden können
– Interfaces werden in der IDL(Interface Definition Language) spezifiziert.
Seminar VA (03/04) 47T.S. (JD)
● Operation
– ein identifizierbarer Eintrag im Interface, der auf einen Dienst verweist, der von Clients über das Interface vom Objekt angefordert werden kann
– Eine Operation wird über einen Objektidentifikator identifiziert.
– Die Signatur beschreibt die erlaubten Parameter und Rückgabewerte.● Parameter
– wird durch seinen Modus (Eingabe und/oder Ausgabe; in, out, inout) und seinen Typ charakterisiert
CORBA-ObjekteBegriffe
Seminar VA (03/04) 48T.S. (JD)
● Attribut
– Interfaces können Attribute beinhalten.
– Ein Attribut ist mit einem Paar von Zugriffsmethoden, Get und Set, verbunden.
● Typ
– Die Angabe eines Typs charakterisiert Parameter oder Rückgabewerte.
– Neben den Objekttypen unterscheidet man bei der OMG einfache Typen, wie zum Beispiel Short, Double, String, sowie die zusammengesetzten Typen Struct, Sequence, Union und Array.
CORBA-ObjekteBegriffe
Seminar VA (03/04) 49T.S. (JD)
Object Management Architecture – en detail
Seminar VA (03/04) 50T.S. (JD)
CORBA - Übersicht
Seminar VA (03/04) 51T.S. (JD)
CORBA – Grundstruktur
Object Request Broker Kernel
DynamicInvocationInterface
ClientIDLStub
ORBInterface
ServerIDL
Skeleton
DynamicSkeleton
Invocation
ObjectAdapter
Es kann mehrere Object Adapter geben.
ORB-spezifische Schnittstelle
standardisierte Schnittstelle (identisch für alle ORB‘s)
Client Object Implementation
mehrerer jeweils auf einen Objekttyp spezialiserte Schnittstellen
Seminar VA (03/04) 52T.S. (JD)
Aufruf von Objektmethoden über Client IDL Stub
Object Request Broker Kernel
ClientIDLStub
Client
Seminar VA (03/04) 53T.S. (JD)
Dynamischer Aufruf von Objektmethoden
Object Request Broker Kernel
DynamicInvocationInterface
ClientInterfaceRepository
Seminar VA (03/04) 54T.S. (JD)
Weiterleitung eines Client-Requests über IDL Skeleton
Object Request Broker Kernel
ObjectAdapter
ObjectImplementation
ImplementationRepository
ServerIDL
Skeleton
Seminar VA (03/04) 55T.S. (JD)
Dynamische Weiterleitung eines Client-Requests
Object Request Broker Kernel
DynamicSkeleton
Invocation
ObjectAdapter
ObjectImplementation
ImplementationRepository
Seminar VA (03/04) 56T.S. (JD)
Client
● Der Client hat Zugriff auf Objektreferenzen.● Erst mit der Objektreferenz wird der Zugriff auf die Dienste (über
Objektoperationen) möglich.● Der Client kennt nur die logische Struktur des Objektes entsprechend dem
Interface und kann auf das Verhalten des Objektes nur über Operationsaufrufe einwirken.
Clients haben keine Kenntnis über die Implementierung des Objekts, welcher Objektadapter oder welcher ORB für den Zugriff benutzt wird.
Objekt-Referenz
• Die Objekt-Referenz ist die Information, die zum Auffinden eines Objektes innerhalb eines ORB‘s benötigt wird.
Sowohl Client als auch Objektimplementierung besitzen eine eindeutige Notation der Objekt-Referenz entsprechend der Programmiersprache.
Seminar VA (03/04) 57T.S. (JD)
Übergabe des Client-Request an das Server-Objekt
● Der ORB– ermittelt den gewünschten Objektimplementierungs-Code– übermittelt die Parameter des Request und – übergibt die Aktivitätssteuerung über das objektspezifische Interface-
Gerüst oder über das dynamische Interface-Gerüst an die Objektimplementierung.
● Die Objektimplementierung– kann während der Ausführung des Auftrages Dienste über den Objekt-
Adapter in Anspruch nehmen und– übermittelt die Ergebniswerte und gibt die Aktivitätssteuerung ab, wenn
der Auftrag erfüllt ist.● Der Object Adapter implementiert die grundlegende Funktionalität zur Arbeit
mit dem Server-Objekt.
Seminar VA (03/04) 58T.S. (JD)
Objektimplementierung
● Die Objektimplementierung liefert die Semantik des Objektes durch– die Datendefinition für die Objektinstanz und– den Code für die Objektmethoden
● Die OMG spezifiziert vier Objektimplementierungen, wobei drei vom Object Adapter aktiviert werden:– shared Server (mehrere Objekte je Server-Prozeß)– unshared Server (ein Objekt je Server-Prozeß)– Server per method (je Methodenaufruf ein Server-Prozeß gestartet,
der nach Ausführung wieder terminiert)● Der permanent Server, als vierte spezifizierte Objektimplementierung, wird
unabhängig vom ORB gestartet und ist ständig aktiv.
Seminar VA (03/04) 59T.S. (JD)
Interoperabilität zwischen ORB‘s
Client
ORB A
Proxy(Server)
Proxy(Client)
ORB B
Server-Objekt
IOP
ORB A generiert ein Proxy-Objekt (Server), welches auf der einen Seite das Interface des gewünschten Server-Objektes (Dynamic Skeleton Invocation) und auf der anderen Seite ein Inter ORB Protokoll unterstützt.ORB B generiert analog dazu ein Proxy-Objekt (Client) für den Zugriff auf das Server-Objekt (Dynamic Invocation Interface) und für die Kommunikation mit ORB A.
GIOP-General Inter ORB ProtocolIIOP-Internet Inter ORB ProtocolESIOP-Environment Specific IOP
Seminar VA (03/04) 60T.S. (JD)
Überblick: CORBAservices
● Naming Service– Auffinden von Objekten im Netz
● Event Service– Behandlung asynchroner Ereignisse
● Life Cycle Service– Regelung des Erzeugens, Kopierens, Verschiebens und des Löschens von
Objekten● Persistance Service
– langfristige Speicherung von Objektzuständen● Security Service
– Schutz des Systems vor unerlaubter Benutzung● Time Service
– Synchronisation von Uhren
Seminar VA (03/04) 61T.S. (JD)
Überblick: CORBAservices
● Concurrency Control Service– Koordinierung von nebenläufigen Aktivitäten (Lock-Manager)
● Transaction Service– flache und geschachtelte Transaktionen auf Objekte
● Relationship Service– dynamische Erstellung von Verbindungen zwischen Objekten, ohne daß
diese Komponenten davon Kenntnis haben, und Traversierung der entstandenen Strukturen
● Externalization Service– Einlesen/Ausgeben der Daten eines Objektes aus/in einem/einen Stream
● Query Service– Manipulation definierter Collections von Objekten durch die Object
Query Language (OQL) beziehungsweise die Structured Query Language (SQL3)
Seminar VA (03/04) 62T.S. (JD)
Überblick: CORBAservices
● Licensing Service
– Überprüfung und Abrechnung der Verwendung von Objekten● Properties Service
– Verbindung von named values (properties) mit beliebigen Objekten, z.B. abhängig vom Zustand des Objektes
● Trading Object Service
– Anbieten (Anmelden) / Anfordern (Auffinden) von speziellen Diensterbringern zur Laufzeit
● Collections Service
– Funktionen zur Verwaltung verschiedenartiger Mengen von Objekten (Collections), wie zum Beispiel Listen, Stacks, Baumstrukturen
Seminar VA (03/04) 63T.S. (JD)
Überblick: CORBAfacilities
● Bereiche für CORBAfacilities:
– User Interface
• z.B. Dienste für Ein- und Ausgabe von Verbunddokumenten
– Information Management
• z.B. Dienste für unternehmensweite Datenhaltung, wie z.B. Konvertierung und Komprimierung
– Systems Management
• administrative Dienste, wie z.B. Verwaltung von Zugriffsrechten
– Task Management
• Dienste zur Unterstützung von Benutzeraufgabe, wie z.B. die Einbindung mobiler und stationärer Agenten
Seminar VA (03/04) 64T.S. (JD)
Anwendungsbeispiele und existierende Produkte
● kommerziell:– Visibroker von Borland (und Visigenic)– Component Broker von IBM
– ...● kostenlos:
– TAO ACEOrb (C++,..; Corba2.5)
– JacOrb (Java; Corba 2.3)
– mico (C++,...; Corba 2.2)– ominorb (C++, Python...; Corba 2.6)
– Java IDL von Sun Microsystems (Corba 2.2)– ...
● Anwendungsbeispiele:– Success Stories: www.corba.org/succ.htm
Seminar VA (03/04) 65T.S. (JD)
CORBA 3
● Die Weiterentwicklungen betreffen 3 Kategorien:
– Internet Integration
– Quality of Service in CORBA
– CORBAcomponent Architektur (nächste Veranstaltung!)● Die erforderlichen Spezifikationen sind größtenteils verfügbar.● Die Integration in die Produkte erfolgt zur Zeit
Seminar VA (03/04) 66T.S. (JD)
Internet Integration
● Firewall Specification
– Internet Inter ORB Protocol (IIOP): Port 683 undInternet Inter ORB Protocol over Secure Socket Layer(IIOP over SSL): Port 684
– Restriktionen für Call Backs vom Server zum Client
● Interoperabler Name Service
– Objekt-Referenzen im URL-Format: iioploc, iiopname
– Beispiel: iioploc://www.tu-ilmenau.de/NameService
Seminar VA (03/04) 67T.S. (JD)
Quality of Service in CORBA
● Asynchronous Messaging und Quality of Service Control– Polling oder Callbacks– Einordnung nach Zeit, Priorität oder Deadline– Setzen von Priorität, Deadline, Time-to-Live, Start- und Endzeit
– Beeinflussung von Routingstrategien und Vorgabe von Routen im Netz
● Minimum CORBA– für eingebettete Systeme
● Real-Time CORBA– Prioritätsgesteuerte Verwaltung von Ressourcen, wie zum Beispiel
Threads und Verbindungen, in Echtzeitumgebungen● Fault-tolerant CORBA
– Redundanz und Fehlermanagement
Seminar VA (03/04) 68T.S. (JD)
Applikationsentwicklung mit IDL
IDL Schnittstellen Definition
IDL Compiler
Client StubsServer
Skeletons
InterfaceRepository
Language Compiler
Client ProgramObject
Implementation
Object Request Broker
Stub Skeleton
Client Program Object Implementation
ImplementationRepository
Seminar VA (03/04) 69T.S. (JD)
Interface Definition Language - IDL
Unabhängigkeit der Definition der Schnittstellen von der benutzten Programmiersprache für– die Schnittstellen der Object Management Architecture und– die Schnittstellen der Server-Objekte des Applikationsentwicklers
● Umsetzung zwischen der IDL-Schnittstellenbeschreibung und der gewählten Implementierungssprache: Mapping für– C, C++, Smalltalk, Java, Ada, Cobol, ...
● keine Konstrukte zur Ablaufsteuerung nötig (deskriptiv)● Vererbung von bereits existierenden Schnittstellen● lexikalische Regeln wie bei C++● Die Menge der Schlüsselwörter von IDL ist eine Untermenge des
ANSI C++ Standards.● Einführung neuer Schlüsselwörter
Seminar VA (03/04) 70T.S. (JD)
IDL: Beispiel Hello.idl
Beispiel einer IDL-Beschreibung für das Interface der Hello-Anwendung
module HelloApp{
interface Hello{
string sayHelloTo(in string helloTO);
};
};
Seminar VA (03/04) 71T.S. (JD)
IDL: ausführliches Beispiel
module BauamtApp { interface Antrag; interface Briefkasten; interface Person; interface Beamter;
interface Antrag { enum Typ {Neubau, Umbau, Sprengung}; attribute string datum; attribute Person antragsteller;
const short max = 1000; typedef string Zeilen[max]; attribute Zeilen inhalt; };
Seminar VA (03/04) 72T.S. (JD)
IDL: Beispiel
interface Briefkasten { void einreichen (in Antrag neuerAntrag); };
interface Person { struct Name { string Vorname; string Nachname; }; union Adresse switch(short) { case 0: string Strasse; case 1: short Postfach; default: string Anschrift; }; void setzeDaten(in Name name, in Adresse adresse); void holeDaten(out Name name, out Adresse adresse); };
Seminar VA (03/04) 73T.S. (JD)
IDL: Beispiel
interface Beamter : Person { typedef sequence <Antrag> AntragSequence; typedef sequence <Antrag, 50> AntragSequence50; AntragSequence stapel();
readonly attribute double Gehalt;
exception Feierabend { string arbeitszeit; };
void bearbeite(in Antrag antrag) raises(Feierabend); };
};