Mediationskomponenten bearbeiten den Nachrichtenfluss zwischen Servicekomponenten.
Die Funktionalität einer Mediationskomponente wird durch primitive Mediationselemente implementiert, die Standardtypen von Serviceimplementierungen implementieren.
Eine Mediationskomponente enthält einen oder mehrere Abläufe, z. B. einen für Anforderungen
und einen für Antworten.
WebSphere Process Server unterstützt eine
bereitgestellte Gruppe von primitiven Mediationselementen, die Standardmediationsfunktionen
für Mediationsmodule implementieren, die unter WebSphere Process Server implementiert sind.
Wenn Sie spezielle Mediationsfunktionen benötigen, können Sie eigene Anpassungen von primitiven
Mediationselementen definieren.
Ein primitives Mediationselement definiert eine "Eingangsoperation", von der Nachrichten
verarbeitet werden, die durch Servicenachrichtenobjekte (Service Message Objects, SMO) dargestellt sind.
Ein primitives Mediationselement kann außerdem
"Ausgabeoperationen" definieren, die Nachrichten an eine andere Komponente oder ein
anderes Modul senden.
Abbildung 1. Mediationsmodul mit drei primitiven Mediationselementen
Primitive Mediationselemente arbeiten normalerweise
auf Einzeloperationsebene mit einer möglichen Vermittlung (Mediation) zwischen Anforderung und
Antwort. In manchen Fällen können Sie primitive Mediationselemente
sogar auf der untergeordneten Ebene eines Einzelparameters für eine Operation angeben. Beispielsweise können
Selektoren auf Operationsebene oder auf Parameterebene verwendet werden.
Mit WebSphere Integration Developer können Sie Mediationskomponenten
grafisch unterstützt aus primitiven Mediationselementen modellieren und assemblieren sowie
Mediationsmodule aus Mediationskomponenten assemblieren.
Unterstützte primitive Mediationselemente
Die folgenden
primitiven Mediationselemente werden von
WebSphere Process Server
unterstützt:
- Custom Mediation
- Ein solches Element führt angepasste Logik aus. Das primitive Element des Typs "Custom Mediation" kann auch eine
externe SCA (Service Component Architecture - Servicekomponentenarchitektur)-Komponente aufrufen, die von Ihnen
bereitgestellt wird.
- Die aufgerufene Operation muss eine bidirektionale Operation sein.
- Die SCA-Komponente, die als Ziel angegeben ist, muss
im gleichen Mediationsmodul wie das primitive
Element des Typs "Custom Mediation" vorhanden sein.
- Database Lookup
- Ein Element dieses Typs ändert Nachrichten und verwendet hierzu Informationen aus einer vom Benutzer bereitgestellten Datenbank.
- Sie müssen eine Datenbank, eine Datenquelle und alle Einstellungen für die Serverauthentifizierung
konfigurieren, die vom primitiven Mediationselement des Typs "Database Lookup" verwendet werden sollen.
- Das primitive Mediationselement des Typs "Database Lookup" kann nur aus einer einzigen Tabelle
Daten lesen.
- Die angegebene Schlüsselspalte muss einen eindeutigen Wert enthalten.
- Die Daten in den Wertspalten müssen entweder ein primitives Java-Element oder eine Java-Zeichenfolge sein (bzw. in ein primitives Java-Element oder eine Java-Zeichenfolge umgesetzt werden können).
- Endpoint Lookup
- Ein Element dieses Typs ermöglicht dynamisches Routing von Anforderungen durch die Suche nach
Serviceendpunkten in einem Repository.
- Serviceendpunktinformationen werden aus einem lokalen oder fernen WSSR
(WebSphere Service Registry and Repository) abgerufen.
- Registry-Änderungen können Sie in der Administrationskonsole der Registry
vornehmen.
- Event Emitter
- Verbessert die Überwachung durch das Ausgeben von Ereignissen innerhalb eines
Mediationsablaufs.
- Dabei werden Common Base Events (CBEs) an einen CEI-Server (CEI = Common
Event Infrastructure) gesendet.
- Um die Event Emitter-Informationen optimal nutzen zu können, müssen
die Ereignisnutzer mit der CBE-Struktur vertraut sein. CBE-Elemente verfügen
über ein Gesamtschema, das jedoch nicht die anwendungsspezifischen Daten modelliert,
die in den erweiterten Datenelementen enthalten sind.
Zum Modellieren der erweiterten Datenelemente generieren die WebSphere Integration Developer-Tools
eine CEI-Ereigniskatalogdefinitionsdatei für jedes konfigurierte primitive Mediationselement
des Typs "Event Emitter".
Ereigniskatalogdefinitionsdateien sind Exportartefakte zu Ihrer Unterstützung. Sie werden
weder von WebSphere Integration Developer noch
von der WebSphere Process Server-Laufzeit verwendet.
Orientieren Sie sich beim Erstellen von Anwendungen, die Ereignisse des Typs "Event Emitter"
empfangen sollen, an den Ereigniskatalogdefinitionsdateien.
- Andere Überwachungseinstellungen können Sie in WebSphere Process Server angeben.
Beispielsweise können Sie Ereignisse überwachen, die von Import- und Exportoperationen
ausgegeben werden.
Das primitive Mediationselement des Typs "Event Emitter" ermöglicht Ihnen das
Senden von Ereignissen aus einer Mediationsablaufkomponente heraus. Anschließend
können Sie Ereignisse des Typs "Event Emitter" im CBE-Browser von
WebSphere Process Server anzeigen.
- Fail
- Ein Element dieses Typs generiert einen Fehler im Ablauf.
- Message Element Setter
- Dieses Element stellt ein einfaches Verfahren zum Festlegen des Inhalts von
Nachrichtenkopf und -text bereit. Es ändert nicht den Nachrichtentyp.
- Message Filter
- Ein Element dieses Typs leitet Nachrichten - abhängig vom Nachrichteninhalt - an unterschiedliche Pfade weiter.
- Message Logger
- Ein Element dieses Typs protokolliert Nachrichten in einer Datenbank. Die Nachrichten werden im XML-Format gespeichert und können daher von allen Anwendungen verarbeitet werden, die XML erkennen.
- Das Datenbankschema ist durch IBM definiert.
- Auf verteilten Plattformen wird bei der Standardinstallation von WebSphere Process Server
ein eigenständiger Anwendungsserver erstellt und eine Cloudscape-Datenbank mit Datenquelle.
WebSphere Integration Developer konfiguriert primitive Mediationselemente des Typs "Message Logger" standardmäßig so, dass diese Cloudscape-Datenbank verwendet wird. Außerdem
stellt WebSphere Process Server ein Script
(createMessageLoggerResource.jacl) bereit, das eine Cloudscape-Datenbank erstellt.
- Mit dem Befehl coreDBUtilty können Sie eine
DB2-Datenbank für Nachrichtenprotokollierung auf einem fernen z/OS-System erstellen.
- Wenn Sie mit der Administrationskonsole eine eigene Datenbank und Datenquelle erstellen wollen,
bietet WebSphere Process Server DDL-Dateien
(Data Definition Language), die das Tabellenschema beschreiben. Die Dateien "Table.ddl" sind unter
"installationsstammverzeichnis/util/EsbLoggerMediation/datenbanktyp/Table.ddl" gespeichert. Hierbei steht datenbanktyp für den Typ der Datenbank,
beispielsweise CLOUDSCAPE_V50. Falls Sie eine eigene Datenbank erstellen und den JNDI-Standardnamen für die Datenquelle verwenden wollen, müssen Sie die Standarddatenquelle entfernen.
- Stop
- Ein Element dieses Typs stoppt einen bestimmten Pfad im Ablauf, ohne eine Ausnahmebedingung zu generieren.
- XSLT
- Ein Element dieses Typs wandelt Nachrichten um.
- Das primitive Mediationselement des Typs "XSLT" kann die Kopfzeilen oder die Hauptteile Ihrer Nachrichten ändern.
- Zur Umwandlung von Nachrichten führen Sie eine Umwandlung nach XSLT 1.0 (Extensible Stylesheet Transformations) aus. Bei der Umsetzung wird eine XML-Serialisierung der Nachricht durchgeführt.
- SplitPath
- Mit einem Element dieses Typs können Sie den Zielservice (oder eine andere Mediation) auswählen, die Daten an ein bestimmtes Ziel weiterleiten und den Routing-Pfad ändern.
- BOMapper
- Mit einem Element dieses Typs können Sie den Zielservice (oder eine andere Mediation) auswählen, die Daten an ein bestimmtes Ziel weiterleiten und den Routing-Pfad ändern.