Verteilte Anwendungen - eris.prakinf.tu-ilmenau.deeris.prakinf.tu-ilmenau.de/edu/teva/folien/BlockS3.pdfSeminar VA (03/04) T.S. (JD) 2 W iederholung letzte Veranstaltung Client/Server-Modell

Seminar VA (03/04) 1T.S. (JD)

Verteilte Anwendungen Seminar

17.01.2004


Wiederholungletzte Veranstaltung

● Client/Server-Modell● Socket-Programmierung

– Kommunikationsbereich

– 5er-Tupel zur Spezifikation

– Einfaches Python-Beispiel

– Java™-Beispiel mit Exception-Handling


Lernziele

Verteilte Anwendungen● Grundlagen zu VA● Entwicklungsumgebungen und RE‘s

– Remote Procedure Call

– Java™ Remote Method Invocation● Einstieg in Middleware

– CORBA


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


Architekturmodelle verteilter Anwendungen

Internet

Client/ServerPeer-to-Peer

RZ

RZ

Cluster/Grids

mgr.

Client

qmast.Internet

execD

Server

Kunden

InternetcomputingVerteiltes Rechnen


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


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


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!


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


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


Herausforderungen für verteilte Anwendungen

• Transparenz

• Interoperabilität

• Fehlerbehandlung

• Datenschutz und Datensicherheit

• Parallelität

• Skalierbarkeit

• Offenheit

• Systemumfang

• Administration


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


Mittel zur LösungKommunikation, Interoperabilität

● Kommunikationsmechanismen:

– IPC

– RPC

– RMI

● Interoperabilität: Verbindung heterogener Einzelsysteme bedarf:

– Standardisierter Protokolle

– Externer Datendarstellung (XDR, CDR)

– Normierter Schnittstellen


Erinnerung:Client/Server-Modell

(Internet)


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


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


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)


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


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)


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


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.


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


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


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 );}


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


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


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


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.


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.


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


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


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“;};


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


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;}


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.


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 + “!“); } ...}


... und nun an die Arbeit!

Nicht vergessen, es darf gefragt werden! ;-)


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


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


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)


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“


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.


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


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)


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)


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.


● 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



● 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.



Object Management Architecture – en detail


CORBA - Übersicht


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


Aufruf von Objektmethoden über Client IDL Stub


ClientIDLStub

Client


Dynamischer Aufruf von Objektmethoden


DynamicInvocationInterface

ClientInterfaceRepository


Weiterleitung eines Client-Requests über IDL Skeleton


ObjectAdapter

ObjectImplementation

ImplementationRepository

ServerIDL

Skeleton


Dynamische Weiterleitung eines Client-Requests


DynamicSkeleton

Invocation

ObjectAdapter

ObjectImplementation



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.


Ü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.


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.


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


Ü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



● 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)



● 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


Ü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


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


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


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


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


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



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


IDL: Beispiel Hello.idl

Beispiel einer IDL-Beschreibung für das Interface der Hello-Anwendung

module HelloApp{

interface Hello{

string sayHelloTo(in string helloTO);

};

};


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; };


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); };


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); };

};

Documents

Verteilte Anwendungen - eris.prakinf.tu-ilmenau.deeris.prakinf.tu-ilmenau.de/edu/teva/folien/BlockS3.pdfSeminar VA (03/04) T.S. (JD) 2 W iederholung letzte Veranstaltung Client/Server-Modell