Broker
Der Broker bezeichnet im Broker Pattern sowohl die zentrale Rolle in diesem Architekturpattern als auch das Gesamtpattern.Um was gehts
Das Broker Pattern dient der Strukturierung verteilter Softwaresystem mit entkoppelten Komponenten. Ein Broker ist für die Kommunikation der Komponenten verantwortlich.Beispiele
- Serviceorientierte Architekturen
- Finanzwelt
Problem
Ein komplexes Softwaresystem soll als Menge von entkoppelten und interagierenden Teilsystemen entworfen werden.Daraus resultieren folgende Konsequenzen: die Teilsysteme sollten
- miteinander kommunizieren
Kommunikationsprotokoll - sich finden Namensdienst
- zur Laufzeit konfiguriert werden Konfigurationsmanagement
- einfach ansprechbar definierte API
Lösung
Führe einen Broker ein, der den Dienstanbieter und den Dienstnutzer zusammenbringt. Die Dienstanbieter registrieren sich beim Broker. Der Client stellt eine Anfrage an den Broker, der ihm dann den Serviceanbieter vermittelt.Der Broker stellte die Infrastruktur für das kommunizieren, das finden und das konfigurieren der Teilssysteme über eine einfache API bereit.
Struktur
Das Broker Architektur Pattern besteht aus sechs Komponenten: Clienten, Servern, Vermittler, Brücken, Stellvertreter auf Client und Server-Seite.- Broker Architektur Pattern:
Server
Der Server stellt die Funktionalität zur Verfügung, die durch eine Schnittstellen-Definitionssprache spezifiziert wird. Hier muß man zwischen zwei Servertypen unterscheiden:- Server, die Funktionalität für die Broker Architektur implementieren ( Namensdienst )
- Server, die die spezifische Funktionalität zur Verfügung stellen
Clienten
Anwendungen, die Funktionalität der Server nutzen, indem sie dem Vermittler Anfragen stellen. Die klassische Trennung Client - Server existiert hier nicht, da Server für die Bearbeitung ihrer Anfrage anderere Server nutzen können (müssen).Vermittler
Bringt den Dienstanbieter und den Dienstnutzer zusammen und stellt ihnen einen Kommunikationskanal zur Verfügung. Der Vermittler nutzt zur Auffindung des Service den Namensdienst. Typischerweise besitzt er eine Registratur für die Services und die Mächtigkeit, den Lebenszyklus der Services zu steuern. Serviceanfragen, die er nicht an seine Services delegiert, leitet er gegebenfalls an anderer Vermittler mittels einer Brücke weiter.clientseitige Stellvertreter ( Stub )
Dieser Proxy befindet sich transparent zwischen dem Clienten und dem Vermittler. Seine Aufgabe besteht im wesentlichen darin, systemspezifsche Funktionalität zu kapseln. Dies kann die Verwaltung des Speichers, der IPC-Mechnismus, das Marshallen oder das Cachen von Daten sein. Oft findet im clientseitigen Proxy eine Abbildung vom Objektmodell des Client zu dem des Vermittlers statt.serverseitige Stellvertreter ( Skeleton )
Der Server Proxy erfüllt die ähnlichen Aufgaben wie der Client Proxy. So übersetzt er die Daten in das Objektformat des Servers.Brücke
Dies Brücke kapselt netzwerkspezifische Funktionalität, damit Vermittler verschiedener Brokerarchitekturen miteinander kommunizieren können.Wenn die Proxys das gleiche Protokoll benutzen, ist es möglich, beide direkt miteinander kommunizieren zu lassen. Dies bezeichnet man auch als direkte Kommunikation, während die indirekte Kommunikation immer über den Vermittler erfolgt.
Dynamische Aspekte
Server registriert sich beim Vermittler
- der Vermittler startet beim initialisieren des Systems und enters its event loop
- der Server startet, initialisiert sich und meldet sich beim Vermittler an
- der Vermittler nimmt die Registratur des Servers entgegen, speichert sie und schickt dem Server eine Bestätigung
- der Server erhält die Bestätigung und enters its event loop
Client sendet eine Anfrage an den Server
- der Client setzte beim Starten eine Anfrage an den Server ab
- der Client-Stub externalisiert ( marshaling oder pack ) die Daten und leitet sie an den lokalen Vermittler weiter
- der Vermittler schaut in seiner Registratur nach und schickt die Anfrage an den Server-Skeleton weiter
- der Server-Skeleton internalisiert ( demarshaling oder unpack ) die Nachricht und ruft den Server auf
- die durch den Server bearbeitete Anfrage wird über den Server-Proxy ( Server-Skeleton ) externalisiert und an den Broker zurückgeschickt
- der Vermittler sendet die Nachricht an den Client-Proxy ( Client-Stub )
- der Client-Proxy internalisiert das Ergebnis und schicket es an den Client, die Applikation
Kommunikation zwischen verschieden Broker Architekturen
- Vermittler A erhält eine Anfrage und stellt fest, daß der Vermittler B im Gegensatz zu ihm einen entsprechenden Server registriert hat
- Broker A schickt die Nachricht an Broker B, nachdem er die Nachricht von seinem Protokoll in ein gemeinsames Protokoll übersetzt hat
- Broker B nimmt die Nachricht in dem gemeinsamen Protokoll an und übersetzt sie in sein spezifisches Protokoll
- ...
Implementierung
- Lege das Objektmodell fest
- Sollen die Serverobjekte zustandslos oder zustandsbehaftet sein?
- Welche Operationen sollen sie unterstützen?
- Wie werden sie instanziiert oder gelöscht?
- Welches Interface benötigen sie intern, zum Broker oder zum Clienten?
- Welche Datentypen, Fehlermeldungen sollen sie unterstützen? Ein sehr ausgereiftes Modell besitzen DeWikipedia:Enterprise_Java_Beans .
- Stelle die Komponenten-Interoperabilität sicher
- Unterstützung eines Binärstandars
- in DeWikipedia:OLE_%28EDV%29 stehen binäre Methodentabellen zur Verfügung, die Zeiger auf die Implementierung der Methode enthalten
- Einführung eines Schnittstellenbeschreibungssprache DeWikipedia:Interface_Definition_Language
IDL bezeichnet sowohl die Interface Definition Language als auch deren konkrete Implementierung in CORBA- sun RPC
- das Programm rpcgen erzeugt aus einer Schnittstellenbeschreibung insbesondere Stubs, Skeletons und eine XDR Datei zur Datenkonvertierung
- rpcgen stellt eine API für entfernte Funktionsaufrufen in Czu Verfügung
square_instruct square_in { /* input (argument) */
long arg1;
};
struct square_out { /* output (result) */
long res1;
};
program SQUARE_PROG {
version SQUARE_VERS {
square_out SQUAREPROC(square_in) = 1; /* procedure number = 1 */
} = 1; /* version number */
} = 0x31230000; /* program number */
- Remote Methode Invocation: RMI
- der rmic Compiler erzeugt aus einem Serverinterface die Stubs und Skeletons in Java
- im Gegensatz zu den Funktionsreferenzen beim sun RPC sind dies Objektreferenzen
- seit Java 5 wird der Stub und Skeleton implizit von der Java Virtual Maschine erstellt
public interface ServerInterface extends Remote
{
public void method() throws RemoteException;
}
- CORBA
- CORBA benutzt die IDL für die Interfacebeschreibung
- war die Interfacebeschreibung in sun RPC C orientiert, so ist die CORBA IDL C++ orientiert
- CORBA verbindet mit RMi, daß hier Objekte referenziert werden
- standardisierte Implementierung eines IDL2Language Compilers gibt es für Ada, C, C++, Lisp, Smalltalk, Java, COBOL, PL/I und Python
module BankSimple {
interface Account {
// Operations available on the account.
void deposit (in float amount);
void withdraw (in float amount);
};
};
- sun RPC
- Web Services
- die Interfacebeschreibungssprache nennt sich hier Web Service Definition Language, kurz wsdl
- dieser xml Dialekt ist deutlicher komplexer: DeWikipedia:WSDL
- im Gegensatz zu den bisherigen IDL's ist die wsdl nicht nur rein deklarativ, sondern sie legt die Art der Daternübertragung und den Servicepunkte fest
- Implementierung eines wsdl2Compiler Codegenerators gibt es in Java, C++, Python, Perl, ...
Sun RPC stellt als einzige dargestellte IDL nur Funktionreferenzen zur Verfügung. Alle anderen bieten Objektreferenzen an. Der wesentliche Unterschied zwischen sun RPC und RMI auf der einen und CORBA und wsdl auf der anderen Seite besteht darin, daß die ersten Lösungen für eine Sprache anbieten. Die wsdl unterscheidet sich von allen anderne IDL#s darin, daß sie über den rein deklarativen Charakter hinausgeht.
- Unterstützung eines Binärstandars
- Spezifiziere das Interface des Vermittlers
- zu den Clienten
- für den Clienten existieren zwei Möglichkeiten Anfragen abzusetzen
- statisch
- der Client weiß ganz genau, welches Services der Vermittler unterstützt
- für die Applikation bedeutet dies, daß sie ihren Aufruf gegen den statisch erzeugen Stub absetzt
- der Vermittler nützt seinen Namensdienst und findet eine eindeutige Abbildung von angefragen Dienst an den Dienstanbieter
- Nutzung eines Nameing Service
- dynamisch
- besitzt der Client nur ein ungefähre Ahnung, nützt der Vermittler Reflektion um den Dienstanbieter ausfindig zu machen
- Nutzung eines Trading Service
- statisch
- für den Clienten existieren zwei Möglichkeiten Anfragen abzusetzen
- zu den Servern
- als Ansprechpartner für die Services benötigt der Broker Schnittstellen um die Serverobjekte zu verwalten
- das anmelden, abmelden, identifizieren, relokieren, starten und überwachen von Services sind denkbare Aufgaben für den Vermittler
- entscheidend für die Schnittstelle ist die Frage, ob man Services statisch oder dynamisch verwaltet
- im statischen Fall kann es für den Vermittler ausreichend sein, eine Konfigurationsdatei über alle verfügbaren Services während seiner Initialisierung einzulesen
- als Ansprechpartner für die Services benötigt der Broker Schnittstellen um die Serverobjekte zu verwalten
- zu den Clienten
- Führe Proxys für die Clienten und Server ein
- so wie der Clientstub für den Clienten den Server repräsentiert, so repräsentiert der Serverskeleton den Client für den Server
- die beiden Proxy helfen insbesondere, das serialisieren und deserialisieren der Anfragen und Antworten der beiden Kommunikationsendpunkten zu verbergen
- durch die Stellvertreter ist es insbesondere möglich, Interoperatibilität zwischen verschiedenen Sprachen zu erreichen
- sowohl Client und Stub wie auch Server und Skeleton laufen im gleichen Prozeß
- entwickle den Vermittler parallel zu den letzten zwei Punkten
Aus Performancegründen kann der Vermittler nur die Verbindung zwischen den Endpunkten einrichten, während der weitere Datenaustausch direkt zwischen dem Clienten und dem Servern, bzw. genauer zwischen dem Stub und dem Skeleton erfolgt. Diese Variante des Broker Patterns wird auch als direktkommunizierende Broker-Systemebezeichnet.- lege das Kommunikationsprotokoll für lokale Brokerarchitektur fest
- CORBA und RMI verwenden gerne das binäre DeWikipedia:IIOP
- Web Services setzten auf den XML Dialekt DeWikipedia:SOAP
- lege ein Brücke für die Interoperatibilität mit andern Broker Architekturen fest
- mit CORBA 2.0 wurde GIOP bzw. sein Implementierung über TCP/IP IIOP spezifiziert, damit verschiedene Broker - Architekturen miteinander kommunizieren können
- spricht die lokale Broker Architektur eine anders Protokoll, sollte man gegebenfalls eine Abbildung von diesem lokalen Protokoll nach IIOP implemtieren
- führe ein Verbindungscookieein
- falls die Serviceanfrage und die Serviceanwort über den Vermittler über den Vermittler geleitet werden, ist es notwendig, daß dieser ein Gedächtnis erhält, damit er die Zuordnung der Serviceantwort zum entsprechend Client vollziehen kann
- dies Gedächtnis ist bei der direkten Variante nicht notwendig, daß hier die zwei Stellvertreter direkt kommunizieren
- implementiere gegebenfalls einen Nachrichtenpuffer
- im Falle einer asynchronen Anfrage ist es notwendig, daß die Ergebnisdaten auf den Serverseite gespeichert werden, bevor sie an den Client übermittelt werden können
- entwerfe eine Fehlerbehandlung
- unterscheide zwischen Kommunikationsfehler und Servicefehlern
- Welche Aktivitäten soll der Vermittler einleiten, wenn die Kommunikations mit anderen Clienten, Vermittlern oder Servern mißlingt?
- Soll eine Aktion durch den Vermittler einmal oder bis zum Erfolgsfall angestossen werden.
- lege das Kommunikationsprotokoll für lokale Brokerarchitektur fest
- Entwerfe einen IDL - Übersetzer
- für jede zu unterstützende Sprache ist eine entsprechende Abbildung der Interfacebeschreibung auf die Implementierungssprache notwendig
Auswirkungen
Vorteile
- Standortunabhängigkeit der Client und Server durch den Vermittler
- der Client ist unabhängig gegenüber Implementierungsänderungen des Servers
- Änderungen der IDL könnnen leicht umgesetzt werden, so daß im Idealfall nur leichte Anpassungen auf Server- und Clientseite vollzogen werden müssen
- leichte Portierbarkeit des Broker-Systems auf neue Systeme, da Client und Server frei von systemspezifischer Funktionalität sind
- definierte Erweiterungspunkte für neu zu unterstützende Sprachen durch die Implementierung eines IDL2Language- Compilers, der für einzubindende Clienten Stubs und für einzubindende Server Skeletons erzeugen muß; dies schließt inbesondere die Umsetzung der IDL Typen auf die Sprachentypen ein
- durch die gemeinsame Sprache IIOP der Brokersysteme, können diese miteinander kommunizieren; CORBA und RMI sprechen beiden IIOP
- neue Services können leicht implementiert werden, da sie Basisservices des Broker Systems nutzen können
Nachteile
- Performanceverlust, denn insbesondere die Abstraktion eines Vermittlers stellt eine Indirektion dar
- die Kommunikation der Parteien hängt von vielen Komponenten ab
Weiterlesen...