EGL-Unterstützung für SOA

EGL bietet zwei Arten der Unterstützung für SOA (Serviceorientierte Architektur): Serviceentwicklung und Servicezugriff.

Serviceentwicklung

Bei EGL beginnt die Entwicklung eines Service mit der Codierung eines Serviceabschnitts. Beispiel:
Service MyServicePart
   value STRING = "Hello ";
   
   function myEcho(myString STRING IN) returns (STRING)
      return (value = myString);
   end
end

Der Inhalt des Serviceabschnitts ist die Serviceimplementierung. In diesem Fall akzeptiert die Implementierung eine Eingabezeichenfolge wie beispielsweise "world" und gibt an den anfordernden Benutzer die Verkettung von "Hello" und der Eingabezeichenfolge zurück. Sie können dem Serviceanforderer mehrere Funktionen oder Serviceoperationen zur Verfügung stellen.

Bei der Erstellung eines Serviceabschnitts geben Sie an, wie dieser implementiert werden soll. Ein Serviceabschnitt kann als einer der folgenden Services implementiert werden:
EGL-Service
Ein EGL-Service tauscht Daten in einem EGL-spezifischen Binärformat aus.

Verschiedene Arten von EGL-Code können auf einen EGL-Service zugreifen und dieser Zugriff erfolgt relativ schnell. Der EGL-Service ist jedoch kein Web-Service und in anderen Sprachen geschriebener Code kann nicht auf ihn zugreifen.

EGL-REST-RPC-Service
EGL-generierte, webbasierte Anforderer können auf einen EGL-REST-RPC-Service zugreifen. Die Daten haben stets das JSON-Format, das keine HEX-, BLOB- oder CLOB-Daten einschließt.

Der Zugriff auf einen EGL-REST-RPC-Service erfolgt immer mit einer POST-Methode, aber dieses Detail bleibt dem Anforderer verborgen. Informationen zu weiteren Details, die für den Zugriff auf einen EGL-REST-RPC-Service durch eine in einer anderen Sprache geschriebenen Logik von Bedeutung sind, finden Sie in 'EGL REST-RPC-Nachrichtenstruktur'.

In Rich-UI-Anwendungen werden die vom Service zurückgegebenen numerischen Daten, die mehr als 15 signifikante Ziffern aufweisen, vom EGL-Laufzeitcode auf- bzw. abgerundet. Bei der Rückgabe von JSON an EGL-generierten Java™-Code erfolgt die Rundung nicht.

SOAP-Service
Ein SOAP-Service ist ein traditioneller Web-Service, auf den in beliebigen Sprachen geschriebener Code zugreifen kann.

Der Zugriff auf einen EGL-generierten Service ist immer mit dem RPC-Stil (nicht mit dem REST-konformen Stil) konform. Die Parameter und ein Rückgabewert geben die Daten an, die ausgetauscht werden sollen. Der Zugriff auf den Service beinhaltet keine Pfadvariablen oder Abfrageparameter.

Codeentwicklung für Servicezugriff

Jeder EGL-Logikabschnitt, auch ein Serviceabschnitt, kann als Serviceanforderer agieren. Auf die folgenden Services ist ein Zugriff möglich:
  • EGL-Service
  • EGL-REST-RPC-Service
  • SOAP-Service (unabhängig davon, ob EGL-generiert oder nicht)
  • IBM® i-Serviceprogramm
  • REST-Service eines anderen Herstellers, der dem REST-Stil weitestgehend entspricht. Die folgenden Varianten werden unterstützt:
    • Einige REST-Services verwenden eine POST-Anforderung für andere Tasks als das Erstellen einer Ressource. Wenn Sie auf einen REST-Service eines anderen Herstellers mit einer POST-Anforderung zugreifen, kann das Senden von Geschäftsdaten vermieden werden.
    • Für einige REST-Services muss eine DELETE-Anforderung eine Darstellung (die Geschäftsdaten) enthalten, anstatt zum Angeben der zu löschenden Ressource den URI zu verwenden. EGL unterstützt den Zugriff auf REST-Services, die eine Darstellung für eine DELETE-Anforderung benötigen, unterstützt aber auch den Zugriff auf REST-Services, die diese Anforderung nicht haben.
Der Servicezugriff beinhaltet normalerweise die folgenden Schritte:
  1. Geben Sie ein Service-Binding an, das aus den für den Zugriff auf den Service erforderlichen Details besteht. Das Service-Binding kann sich im Anforderer oder im EGL-Implementierungsdeskriptor befinden. Verwenden Sie wenn möglich den Implementierungsdeskriptor, da das Konfigurationspersonal das Service-Binding aktualisieren kann, ohne den Anforderer aktualisieren und neu generieren zu müssen.
  2. Erstellen Sie einen Schnittstellenabschnitt, der auf dem Service basiert. Der Schnittstellenabschnitt beinhaltet Funktionsprototypen. Diese Funktionsprototypen sind Definitionen, welche die Parameter und Rückgabewerttypen für jede Funktion angeben, auf die ein Zugriff möglich ist. Sie können den Schnittstellenabschnitt schreiben oder mithilfe der Workbench eine automatische Erstellung aus einem EGL-Serviceabschnitt oder einer WSDL-Datei veranlassen.

    Wenn Sie auf einen in EGL geschriebenen Service zugreifen, müssen Sie keinen Schnittstellenabschnitt erstellen, sondern können den Serviceabschnitt wie einen Schnittstellenabschnitt verwenden.

  3. Deklarieren Sie eine Variable, für die der Schnittstellenabschnitt die Typdefinition ist. Beispiel: Wenn der Name des Schnittstellenabschnitts IMyService lautet, der Name der Variablen myService lautet und ein Implementierungsdeskriptoreintrag ebenfalls IMyService lautet, sieht die Variablendeklaration wie folgt aus:
    myService IMyService{};

Details zu den Datentypen, die an Services gesendet oder von diesen zurückgegeben werden, finden Sie in 'Einschränkungen bei den für den Servicezugriff verwendeten Prototypen'.

Obwohl Sie einen EGL-Serviceabschnitt als Schnittstellenabschnitt verwenden können, sollte in den meisten Fällen ein separater Schnittstellenabschnitt verwendet werden. Zum Beispiel wenn Sie die Verteilung einer Serviceimplementierung an andere Entwickler vermeiden möchten, weil der Service änderbar oder vertraulich ist. Beim Zugriff auf einen dedizierten Service über eine Rich-UI-Anwendung müssen Sie jedoch einen Serviceabschnitt als Schnittstellenabschnitt verwenden (siehe 'Servicezugriff in Rich UI).

Web-Serviceimplementierung

Die Laufzeitarchitektur weist für alle EGL-Web-Serviceimplementierungen dasselbe Muster auf: generierter oder Laufzeitcode fungiert als Zwischenstation zwischen dem Anforderer und dem Service. Der zwischengeschaltete Code konvertiert Daten zwischen dem textbasierten Format einer Servicenachricht und dem vom Service geforderten Binärformat.

Übersicht über die einzelnen Implementierungstypen:
  • Bei der Generierung eines EGL-REST-RPC-Service ist die Ausgabe eine Gruppe von Java-Klassen. Wenn Sie den Implementierungsdeskriptor generieren oder implementieren, beinhaltet die Ausgabe eine XML-Datei, welche die Serviceposition angibt.

    Die Laufzeitplattform ist ein mit Java EE kompatibler Anwendungsserver. Dort liest der EGL-Laufzeitcode die XML-Datei, ruft den Service auf und fungiert als Zwischenstation zwischen dem Anforderer und dem Service.

  • Bei der Generierung eines auf Java basierenden SOAP-Service ist die Ausgabe eine Gruppe von Java-Klassen. Wenn Sie den Implementierungsdeskriptor generieren oder implementieren, beinhaltet die Ausgabe eine Java-Klasse, die als Service-Wrapper bezeichnet wird. Dieser Service-Wrapper unterscheidet sich von der EGL-generierten Ausgabe (siehe 'Java-Wrapper generieren'). Die Laufzeitplattform ist ein mit Java EE kompatibler Anwendungsserver. Der Anwendungsserver ruft den Service-Wrapper auf, der wiederum den Service aufruft und als Zwischenstation zwischen dem Anforderer und dem Service fungiert. Der Service-Wrapper und der Service sind zueinander lokal.
  • Bei der Generierung eines COBOL-basierten SOAP-Service für IBM i ist die Ausgabe ein COBOL-Programm. Wenn Sie den Implementierungsdeskriptor generieren oder implementieren, beinhaltet die Ausgabe einen EGL-generierten Service-Wrapper, der eine Java-Klasse ist.
    Die Situation ist mit dem Fall eines Java-basierten SOAP-Service identisch, allerdings ist der Service-Wrapper über Fernzugriff mit dem Service verbunden. Es gibt zwei Laufzeitplattformen:
    • Ein mit Java EE kompatibler Anwendungsserver ruft den lokalen Service-Wrapper auf, der als Zwischenstation zwischen dem Anforderer und dem EGL-COBOL-Laufzeitcode unter IBM i fungiert.
    • Der EGL-COBOL-Laufzeitcode wird von einer IBM i-Installation ausgeführt. Der Laufzeitcode enthält ein Catcherprogramm, mit dessen Logik die Datenkonvertierung zwischen Java und COBOL erfolgt.

    Der Service-Wrapper verwendet zur Kommunikation mit dem fernen Catcherprogramm das Java400- oder Java400J2C-Protokoll. Das Catcherprogramm ruft den Service auf und fungiert als Zwischenstation zwischen dem Service-Wrapper und dem Service.

  • Bei der Generierung eines auf COBOL für CICS basierenden SOAP-Service ist die Ausgabe ein COBOL-Programm. Wenn Sie den Implementierungsdeskriptor generieren oder implementieren, wird von CICS ein zweites als Service-Wrapper bezeichnetes EGL-generiertes COBOL-Programm bereitgestellt. Eine weitere vom Implementierungsdeskriptor generierte Ausgabe ist eine WSBIND-Datei.
    Die Laufzeitplattform ist CICS, die folgende Aktionen ausführt:
    • Mithilfe der WSBIND-Datei wird der Inhalt der SOAP-Rahmenanweisung in ein Binärformat konvertiert.
    • Der Service-Wrapper wird aufgerufen, der als Zwischenstation zwischen dem Anforderer und dem Service fungiert.

    Der Service-Wrapper und der Service sind zueinander lokal.

Servicezugriff

Der Servicezugriff von einem EGL-generierten Anforderer folgt einem konsistenten Muster: Ein Proxy fungiert als Zwischenstation zwischen dem EGL-generierten Anforderer und dem Service. Der Proxy konvertiert Daten zwischen dem vom Anforderer verwendeten Format und dem vom Service geforderten Format. Wenn ein EGL-Service für den Anforderer jedoch lokal ist, wird kein Proxy verwendet.

In der folgenden Tabelle finden Sie weitere, nach Servicetyp unterteilte Informationen.

Merkmale des angeforderten Service Merkmale des implementierten Anforderers Merkmale des Proxy
dedizierter EGL-Service HTML-Datei mit integriertem JavaScript Der Proxy befindet sich im EGL-Laufzeitcode und ruft den Service lokal (ohne eine HTTP-Anforderung) auf.
lokaler EGL-Service EGL-generierter Java-Code Es wird kein Proxy verwendet.
EGL-generiertes COBOL-Programm
ferner EGL-Service EGL-generierter Java-Code Der Proxy befindet sich im EGL-Laufzeitcode.
EGL-generiertes COBOL-Programm Der Zugriff wird nicht unterstützt.
REST- oder EGL-REST-RPC-Service EGL-generierter Java-Code oder HTML-Datei mit integriertem JavaScript Der Proxy befindet sich im EGL-Laufzeitcode.
EGL-generiertes COBOL-Programm Der Zugriff wird nicht unterstützt.
SOAP-Service EGL-generierter Java-Code oder eine HTML-Datei mit integriertem JavaScript, die auf einem Anwendungsserver implementiert ist, der mit Java EE vollständig kompatibel ist (z. B. IBM WebSphere Application Server) Der Proxy ist eine Java-Klasse, die über den anfordererspezifischen Implementierungsdeskriptor generiert wird.
EGL-generierter Java-Code oder eine HTML-Datei mit integriertem JavaScript, die auf einer beliebigen anderen Plattform implementiert ist Der Proxy befindet sich im EGL-Laufzeitcode.
EGL-generiertes COBOL-Programm Der Proxy ist ein COBOL-Programm, das über den anfordererspezifischen Implementierungsdeskriptor generiert wird.

Ein weiterer Aspekt des Servicezugriffs ist die Position der Service-Bindingdetails. Für alle EGL-generierten Anforderer neben den CICS-Programmen befinden sich die Details in einer XML-Datei, die über den anfordererspezifischen Implementierungsdeskriptor generiert und mit dem Anforderer implementiert wird. Bei einem CICS-Programm werden die Details im Programm selbst generiert.

EGL-generierter Java- und COBOL-Code werden verwendet, wenn ein EGL-generiertes COBOL-Programm unter IBM i implementiert wird und auf einen SOAP-Service zugreift. Die folgenden Laufzeitereignisse geben Aufschluss über die Auswirkungen dieses Verhaltens:
  1. Der EGL-generierte Code ruft den lokalen, EGL-generierten Proxy auf.
  2. Der Proxy ruft den EGL-COBOL-Laufzeitcode auf; genauer gesagt das Catcherprogramm, über das die Datenkonvertierung zwischen COBOL und Java erfolgt.
  3. Das Catcherprogramm verwendet JNI (Java Native Interface) zum Aufrufen des EGL-Java-Laufzeitcodes, der auf der JVM (Java Virtual Machine) unter IBM i ausgeführt wird.
  4. Der EGL-Java-Laufzeitcode greift entweder lokal oder über Fernzugriff auf den SOAP-Service zu.

Der erste Aufruf des Proxy ist langsam, da der Java-Laufzeitcode geladen werden muss, einschließlich aller JAR-Dateien im Klassenpfad. Der Ladevorgang findet nur beim ersten Aufruf oder nach dem Entladen der JVM aus dem Speicher durch IBM i statt.

Sicherheit im Web

Eine Java-Laufzeiteigenschaft gibt an, ob die von EGL REST-RPC-Services zurückgegebenen Ausnahmebedingungen die größtmögliche Detailstufe enthalten. Weitere Informationen finden Sie unter "Beschreibung der Java-Laufzeiteigenschaften", insbesondere unter dem Eintrag für "egl.service.rest.exception.debug". Diese Eigenschaft ist ab Version 8.5 des EGL-Laufzeitcodes wirksam.

Unterstützung für WS-Addressing und WS-Security

Wenn Sie EGL-generierte SOAP-Services oder EGL-generierte SOAP-Serviceanforderer auf IBM WebSphere Application Server implementieren, können Sie die Funktion von WS-Addressing und WS-Security dieses Anwendungsservers verwenden. Der Service oder Serviceanforderer muss auf JAX-WS basieren und nicht auf JAX-RPC (siehe EGL-Unterstützung für JAX-WS und JAX-RPC).

Protokolle

Beim Zugriff auf Web-Services wird immer das HTTP-Protokoll verwendet; für den Zugriff auf COBOL-Web-Services und in anderen Fällen werden allerdings andere Protokolle verwendet. Details hierzu finden Sie in 'Gemeinsame Protokolle'.


Feedback