EGL bietet zwei Arten der Unterstützung für SOA (Serviceorientierte Architektur): Serviceentwicklung und Servicezugriff.
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.
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.
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.
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.
Wenn Sie auf einen in EGL geschriebenen Service zugreifen, müssen Sie keinen Schnittstellenabschnitt erstellen, sondern können den Serviceabschnitt wie einen Schnittstellenabschnitt verwenden.
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).
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.
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.
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.
Der Service-Wrapper und der Service sind zueinander lokal.
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.
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.
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.
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).
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'.