Flink-ESB Message Gateway
Ein Zugangspunkt zu allen DienstenSicherheitsschicht hinzufügenJMS Dienste über HTTP aufrufenDienste formatunabhängig aufrufenInterne und externe Dienste erreichenRiesige Daten handhaben (> 500 GB)Einen Zugangspunkt zu allen Diensten herstellenSicherheitsschicht zu Ihren Diensten hinzufügenJMS Dienste über HTTP aufrufenDienste über verschiedene Formate aufrufenInterne und externe Dienste erreichenRiesige Daten handhaben (> 500 GB unterstützt)
Verwenden Sie Flink-ESB Message-Gateway Konfig-Konsole oder SQL-Skripte zum schnellen Konfigurieren von Gateway Instanzen
Jede beliebige Anzahl von Message-Gateway Instanzen kann von einer DB Konfiguration gestartet werden. Sie können sogar mehrere Message-Gateway Instanzen in verschiedenen Umgebungen haben, welche dieselbe Datenbank nutzen
Verwenden Sie Konfigurationsgruppen um verschiedene laufende Instanzen auf den verschiedenen URIs zu haben
Klonen Ste die Konfiguration in mehreren Umgebungen mittels SQL-Skripte. Anpassungen in der Datenbank werden zur Erstellung neuer Umgebungen aus der bereits vorhandenen nicht benötigt
Jegliche umgebungsspezifischen Daten können und sollten durch Projektvariabeln ersetzt werden
Wenden Sie Änderungen zur Konfiguration an und senden Sie diese an die laufenden Instanzen ohne Auszeit
100% Flexibilität beim Definieren Ihrer Regeln für Request-Validierungen, Request- und Response-Transformationen und Auswahl der Ziele
Trotz der Flexibilität ist es sehr schnell und in der Lage jeden beliebigen Traffic zu handhaben
Fügen Sie Sicherheitsrichtlinien zu den ausgewählten Einträgen hinzu. Die folgenden Authentifizierungsmechanismen werden unterstützt: LDAP, Datenbank oder Datei. Mit LDAP-Authentifizierung können Sie zusätzlich noch eine beliebige Route definieren, sodass Sie über LDAP authentifizieren, aber gleichzeitig die Flexibilität haben die Rollen zuzuweisen, wie es für Ihr Projekt am besten passt
Transformieren Sie jegliches Nachrichtenformat in ein anderes beliebiges Nachrichtenformat. Keine Ausnahmen bezüglich dieser Regel. Z.B. Sie können REST-GET-Anfragen empfangen, sie in SOAP umwandeln, JMS-Eigenschaften setzen und sie in die JMS-Queues schicken
Automatische Protokoll-Umwandlung zwischen HTTP / HTTPS / JMS
Benutzen Sie, falls notwendig, die Zugangsdaten (Nutzername/Passwort), zum Erreichen Ihrer Ziele
Wenn das direkte Erreichen von Zielen nicht möglich ist, definieren und ordnen Sie eine beliebige Anzahl an verschiedenen Proxies, die dazu verwendet werden
Arbeiten Sie mit riesigen Dateien (> 500 GB) ohne Ihren internen Speicher aufzubrauchen
Einfache Konfiguration
Es spielt keine Role, ob Sie nur einige oder hunderte Services über Flink-ESB Message-Gateway erreichen wollen. Die Konfiguration wird so leicht wie das Halten mehrerer SQL Statements oder das Eintreten in eine Konfig-Konsole
Konfigurieren Sie es nur 1Mal im Test oder der Entwicklungsumgebung. Klonen Sie Ihre Konfiguration um Ihre Produktionsentwicklung innerhalb von Sekunden zu steigern
Sie können die Konfigurationszugänge der Konfig-Konsole verweigern und/oder zulassen. Zusätzlich können Sie SQL-Skripte nutze ohne Eingänge zu löschen
Ordnen Sie eine oder mehrere Gruppen den Konfig-Eingängen zu, um mehrere Gateway Instanzen der selben Konfiguration nutzen zu können, die sich mit unterschiedlichen URLs beschäftigen
Flexible Authentifizierung / Autorisierung
Legen Sie fest welche Dienste passwortgeschütz sein sollen, indem Sie eine oder mehrere Rollen den jeweilig verantwortlichen Fassade-Eingängen zuordnen
Drei Typen der Authentifizierung werden unterstützt: FORM, BASIC und DIGEST. Entscheiden Sie, ob Sie gegen LDAP, Database oder File authentifizieren wollen. Mit der LDAP-Authentifikation könnene Sie es beim Verwenden der Gebrauchsroute verbessern, sodass Sie andere Nutzer mit Ihrer gemeinsamen LDAP authentifizieren können, und trotzdem noch die Flexibilität der Verteilung der Nutzerrollen Ihren Bedürfnissen noch beibehalten
Konfigurieren Sie Nutzername/Passwort für HTTP-Ziele, die eine Authentifizierung der Nutzer verlangen
Verwendung von Project-Parametern
Einige Konfigurationseingänge beinhalten umweltspezifische Parameter. Zum Beispiel beinhaltet die Zielexpression gewöhnlicherweise den HTTP Gastgebernamen und Öffnung, wo ein bestimmter Service vorhanden ist, oder wenn der Service passwortgeschützt ist, sind Nutzername und Passwort definiert. Solche umweltspezifischen Werte differieren von Umwelt zu Umwelt
Ersätzen Sie solche umweltspezifischen Werte durch "Projekt-Parameter", wenn Sie Ihre Konfiguration schnell für mehrere Umgebungen klonen wollen
Als Faustregel gilt: keine umweltspezifischen Werte sollten in einer Datenbank-Konfiguration verwendet werden. Alle derartigen Werte sollten durch Projekt-Variabeln ersetzt werden
Sowohl das Übertragen einer vorhandenen Anwendung in die Cloud, als auch das hochstellen einer neuen Anwendung (oder auch beides) ist mithilfe eines zentralen Zugangspunktes sehr viel leichter
Diese Veränderung wird für Ihre Service-und Anwendunggsnutzer bei der Verwendung Ihrer Services via Message Gateway leicht durchschaubar sein/p>
Sie werden weiterhin die selben URLs verwenden, also werden keine Änderungen der vorhandenen Anwendungen benötigt
Sie können Sicherheitsschichten über den Fassade-Eingang hinzufügen und kontrollieren wer welchen Service nutzen kann, bzw. darf
Übertragen Sie die Anwendungen einzeln oder in Grüppchen. Vergessen Sie nicht Ihr Message Gateway zum Reflektieren zu konfigurieren
Mit Gateway Message können Sie diese Aufgabe ohne Service-Downtime planen. Setzen Sie Ihre Anwendungen in die Cloud, fügen Sie Konfigurationen zur Message Gateway hinzu, stellen Sie sicher, dass alle Services auf ihren neuen Plätzen zugänglich sind
(Flink-ESB Admin Console hilft Ihnen beim Testen relevanter Services), teilen Sie anschließend die existierenden URLs auf Message Gateway, um auf die neuen Ziele hinzuweisen
Sie müssen nichts neustarten, laden sie ausschließlich Ihre neue Anwendung hoch
Falls Sie eine oder mehrere Anwendungen zurückrollen wollen um einige Probleme zu lösen, können Sie dies ebenfalls ohen Ausfall machen. Sie müssen diese Anwendungen lediglich umsetzen, testen und sie anschließend für jeden zugänglich machen. Die gesamte Aktivität zurückzurollen ist sogar noch einfacher. Da die ganze Konfiguration in der Datenbank gesichert ist, müssen Sie nur die Datenbank in ihrem früheren Zustand wiederherstellen und die Konfiguration hochstellen
Wenn Sie sich Sorgen um einen Fehler bei Ihren Services mit Message Gateway machen ,können Sie so viele Gateway Instanzen starten wie Sie zur Verarbeitung Ihrer Datenmenge benötigen und so eine reibungslose Operation trotz möglicher Abstürze versichern
Fall 1: Das Buchen von Services ist über 3 JMS-Queues verfügbar. Tickets mit Priorität 1 werden an der Schlange gegeben "urgent", Priorität 2 und 3 - in der Schlange "normal", Priorität 4 - in der Schlange "slow". Nachrichten müssen in XML-Format sein, wie im Schema-File definiert "ticket.xsd". Die Aufgabe ist es einen HTTP POST-Zugang auf Flink-ESB Message Gateway zu erstellen, der Anfragen gegen XSD-Files bestätigt und sie bezüglich ihrer Priorität zur relevanten Schlange leitet. Nutzen Sie Flink-ESB Konfig-Konsole um neue Fassade-Eingänge zu kreieren. Verwenden Sie Flink-ESB Admin-Konsole um den neuen HTTP POST Service zu testen und variieren Sie dessen Funktionalität
Fall 2: Der CD Katalog Service ist auf dem entfernen Server unter http://192.168.2.110:9090/catalogue/cd verfügbar. Dieser Service sucht mithilfe der ID die CD im Katalog. Nachrichten werden im XML-Format erwartet. Die Aufgabe ist es den REST-GET-Zugang auf Flink-ESB Message Gateway mit URI /catalogue/cd/{id} zu erschaffen, welche die Nachrichten in XML-Format generieren, sowie der Katalog-Service es erwartet und sie zum Katalog-Service senden würde. Die Antwort sollte mithilfe des XSLT-Skirpts transformiert werden. Message Gateway sollte ebenfalls den HTTP -"Content-Type" -header hinzufügen um Anfordern und Antworten zu können
Fall 3: Der CD Katalog "AddCD" Service ist auf dem entfernten Server unter http://192.168.2.110:9090/add/cd verfügbar. Dieser Service fügt CD vom Anfrage-XML zum Katalog hinzu. Die Aufgabe ist es den Fassade-Eingang auf Message Gateway für HTTP method POST unter dem URI /calalogue/cd zu erstellen. Die Anfrage muss bestätigt werden (mandatorische Felder "id", "title", "artist" müssen überprüft werden). Die Nachricht muss an http://192.168.2.110:9090/add/cd über HTTP-Proxy gesendet werden. HTTP-Header "Content-Type" müssen hinzugefügt werden
Fall 4: Die CD Katalog "ModifyCD" und "DeleteCD" Services sind auf dem entfernten Serven unter http://192.168.2.110:9090/modify/cd und http://192.168.2.110:9090/delete/cd verfügbar. Diese Services modifizieren oder beseitigen die CD vom Katalog. Nachrichten müssen in XML-Format sein. Die Aufgabe ist es Fassade-Eingänge auf Message Gateway für HTTP PUT über den URI /calalogue/cd and for HTTP DELETE on URI /catalogue/cd/{id} zu erstellen. Die Aufforderung für "ModifyCD" muss bestätigt werden (mandatorische Felder "id", "title", "artist" müssen überprüft werden). Die Nachricht muss an 192.168.2.110:9090 über den im Tutorial für Fall 3 erstellten HTTP-Proxy gesendet werden. Der HTTP-Header "Content-Type" muss an Die Anfragen und Antworten hinzugefügt werden. Auch die Authentifikation muss zu allen Katalog Services "SearchCD" von Tutorial 2, "AddCD" von Tutorial 3, "ModifyCD" und "DeleteCD" hinzugefügt werden. Auschließlich User mit den Rollen "user" oder "admin" sollten suchen können. Nur User mit der Rolle "admin" sollten etwas einsetzen, modifizieren und löschen können
Definieren Sie Fassadeeinträge (URI wo die Dienste erreichbar werden sollen)
Verwenden Sie Message-Gateway Konfig-Konsole oder SQL-Skripte um Fassade-Einträge zu definieren
Diese Einträge enthalten: URIs, auf denen Message-Gateway eingehende Anfragen behandelt werden; HTTP-Methode (GET, POST, PUT oder DELETE); Sicherheitsrollen (Sie können keine Rollen definieren, was bedeutet, dass keine Authentifizierung erforderlich ist, oder eine oder mehrere Rollen - um diese URL zu schützen); Gruppe: ein oder mehrere Strings, die helfen Dienste zu gruppieren
Sie können URI als reguläre Ausdrücke definieren, wie "/.*". In diesem Fall werden alle Anfragen die beim Message-Gateway aufschlagen durch diesen Kanal behandelt
Markieren Sie Fassade-Eintrag mit "stream_mode" um große Dateien zu handhaben, ohne internen Speicher zu verbrauchen (Dateien größer als 500 GB werden unterstützt)
Markieren Sie Fassade-Eintrag als "disabled" um Eintrag zu deaktivieren (zB vorübergehend), ohne ihn vollständig zu löschen. Sie können ihn jederzeit später wieder reaktivieren oder löschen
Definieren Sie die Validierungsregeln die Sie an eingehenden Requests anwenden könnten
Verwenden Sie Message-Gateway Konfig-Konsole oder SQL-Skripte um Validierungsregeln zu definieren
Dies sind Regeln, die Sie dem Fassade-Eintrag zuweisen könnten um eingehende Anfragen nach ihrer Gültigkeit zu prüfen. Es gibt zwei Arten von Regeln: SCHEMA und CUSTOM
Beim Typ SCHEMA definieren Sie URL der XSD-Schemadatei (auf Dateisystem, HTTP-URL oder FTP-URL). Message-Gateway wird eingehende Anfragen gegen diese Schemadatei parsen, wenn diese Regel dem Fassade-Eintrag zugeordnet ist. Das Parsen gegen die Schemadatei schlägt fehl - Antrag wird abgelehnt
Beim Typ CUSTOM definieren Sie einen beliebigen MVEL-Ausdruck, der entweder "true" oder "false" zurückliefern sollte. "false" wird zurückgegeben - Anfrage wird abgelehnt. Mit diesem Regeltyp können Sie jede Art von Prüfungen hinzufügen. MVEL-Ausdruck ist entweder statisch oder dynamisch. Dynamisch bedeutet, es returniert unterschiedliche Ergebnisse je nach Inhalt der eingehenden Nachricht
Sie können zero oder mehrere Validierungsregeln jedem Fassade-Eintrag zuweisen. Request passiert Validierung nur dann erfolgreich, falls alle relevanten Validierungsregeln "true" geliefert haben
Definieren Sie eine benutzerdefinierte Fehlermeldung (wenn Sie möchten) für einige Regeln, und es wird an den Aufrufer zurückgegeben, wenn diese Regel fehlschlägt
Definieren Sie die Transformationsregeln die Sie an Requests oder Responses anwenden könnten
Verwenden Sie Message-Gateway Konfig-Konsole oder SQL-Skripte um Nachrichtentransformationsregeln zu definieren. Diese Regeln können den Anfragen und / oder Antworten zugeordnet werden
Es gibt drei Arten von Transformationsregeln: XSLT, TEMPLATE und CUSTOM
Verwenden Sie XSLT-Transformationsregel, wenn eine Nachricht im XML-Format erwartet wird, die in ein anderes Format mit XSLT umgewandelt werden soll. Definieren Sie URL der XSLT-Datei (kann auf Dateisystem sein, HTTP oder FTP)
Verwenden Sie TEMPLATE-Transformation um Nachricht von einem beliebigen Format in ein anderes beliebiges Format zu konvertieren. Sie können zum Beispiel problemlos XML in JSON transformieren, JSON in HTTP, oder REST GET URL in ein beliebiges Format umwandeln
Verwenden Sie benutzerdefinierte MVEL-Ausdrücke um eine Nachricht zu konvertieren. Der MVEL-Ausdruck ist entweder statisch oder dynamisch. Dynamisch bedeutet, es kann unterschiedliche Ergebnisse liefern je nach Inhalt der Anfrage und / oder der Antwort oder anderer Parametern
Sie können keine oder eine Transformationsregel der Anfrage und / oder Antwort zuordnen
Definieren Sie die Message-Properties die Sie als HTTP-Headers oder JMS-Properties den Requests oder Responses hinzufügen könnten
Verwenden Sie Message-Gateway Konfig-Konsole oder SQL-Skripte um Nachrichteneigenschaften zu definieren. Diese Eigenschaften können den Anfragen und / oder Antworten als HTTP-Header oder JMS-Eigenschaften hinzugefügt werden
Definieren Sie Message-Property (statischer String-Wert) und Wertausdruck, der entweder statisch ist oder den dynamischen MVEL-Ausdruck darstellt. Dynamisch bedeutet, es kann unterschiedliche Ergebnisse liefern je nach Inhalt der Anfrage und / oder der Antwort oder anderer Parametern
Sie können zero oder mehrere Nachrichteneigenschaften jedem Request / Response zuweisen
Definieren Sie die Ziele wo interne Dienste erreicht werden können
Verwenden Sie die Message-Gateway Konfig-Konsole oder SQL-Skripte um Ziele zu definieren. Dies sind HTTP-URLs oder JMS-Queues, in denen ein Dienst, den Sie über die Nachrichten Gateway-URI nach außen ausstellen, intern verfügbar ist
Das Ziel könnte entweder ein HTTP- / HTTPS-URL oder eine JMS-Warteschlange sein. Für HTTP / HTTPS wählen Sie HTTP-Methode unter GET, POST, PUT oder DELETE. Für JMS wählen Sie zwischen REQUEST_REPLY und REQUEST_ONLY
Definieren Sie Benutzer / Passwort für Ziele, die eine Authentifizierung erfordern
Wenn das HTTP- / HTTPS-Ziel nur über einen Proxy erreichbar ist, können Sie das Proxy relevanten Zielen zuweisen. Sie können eine beliebige Anzahl von Proxies hinzufügen / ändern / entfernen, wenn nötig
Weisen Sie Validierungs- und Transformationsregeln, Message-Properties, Ziele den Fassadeeinträgen zu
Verwenden Sie die Message-Gateway Konfig-Konsole oder SQL-Skripte um Validierungs- und / oder Transformationsregeln, Nachrichteneigenschaften und Ziele den Fassadeeinträgen zuzuordnen
Weisen Sie null oder mehrere Validierungsregeln den Fassade-Einträgen zu. Definieren Sie "Bedingung" als MVEL-Ausdruck und lassen Sie eine Regel nur dann gelten, wenn diese Bedingung "true" zurückgibt. Benutzen Sie "Ranking" um die Reihenfolge Regeln-Anwendung zu bestimmen. Bei Bedarf können Sie eine beliebige Zuordnung aktivieren / deaktivieren, ohne eine Zuordnung oder Regel zu löschen
Weisen Sie null oder mehrere Transformationsregeln den Fassade-Einträgen zu (nur zero oder eine Regel wird angewendet, ausgewählt basierend auf "Bedingung" und / oder "Ranking"). Sie können Regeln den Anfragen und Antworten separat zuweisen. Definieren Sie "Bedingung" als MVEL-Ausdruck und lassen Sie eine Regel nur dann gelten, wenn diese Bedingung "true" zurückgibt. Benutzen Sie "Ranking" zum Bestimmen der Reieinfolge in der die Regeln geprüft werden sollen. Bei Bedarf können Sie eine beliebige Zuordnung aktivieren / deaktivieren, ohne eine Zuordnung oder Regel zu löschen
Weisen Sie keine oder mehrere Nachrichteneigenschaften den Fassade-Einträgen zu. Sie können separat Nachrichteneigenschaften für Anfragen und Antworten zuweisen. Definieren Sie "Bedingung" als-MVEL Ausdruck und lassen Sie die Eigenschaft als HTTP-Header oder JMS-Property nur dann hinzufügen, wenn dieser Bedingung "true" zurückgibt. Für die Anfragen, falls Ziel HTTP-Destination ist - werden die Nachrichteneigenschaften HTTP-Header hinzugefügt, für JMS - als JMS-Eigenschaften. Für die Antworten werden die Nachrichteneigenschaften als HTTP-Header hinzugefügt. Bei Bedarf können Sie eine beliebige Zuordnung aktivieren / deaktivieren, ohne Zuordnung oder Eigenschaft löschen zu müssen
Ordnen Sie ein oder mehrere Ziele zuden Fassade-Einträgen. Sie können Ziele verschiedener Typen (JMS und HTTP) dem gleichen Fassade-Eintrag zuweisen. Das Ziel ist gewählt, basierend auf "Bedingung" und / oder "Ranking". Bei Bedarf können Sie ein beliebiges Ziel aktivieren / deaktivieren, ohne eine Zuordnung oder Ziel zu löschen
Publizieren Sie die Konfiguration an die laufenden Message Gateway Instanzen
Verwenden Sie die Message-Gateway Konfig-Konsole um Konfigurationsänderungen an alle laufenden Instanzen zu veröffentlichen oder verwenden Sie die Flink-ESB Admin-Konsole um Message-Gateway auf jeder Instanze separat neu zu initialisieren
Änderungen, die über die Konfig-Konsole oder SQL-Skripte angewendet wurden sind, werden sofort auf Instanzen von Message-Gateway ausgeführt, ohne sie neu starten zu müssen