Der Servicezugriff in einem EGL-Rich-UI-Handler oder in einer entsprechenden Bibliothek erfolgt stets
asynchron: Die Ausführung des Anforderers wird fortgesetzt, ohne auf eine Antwort des Service
zu warten. Der Benutzer kann weiterhin mit der Benutzerschnittstelle interagieren, während der Anforderer auf
die Antwort des Service wartet.
Der folgende Code greift auf die in 'EGL-Unterstützung für SOA' gezeigte
Implementierung zu:
myService MyServicePart{};
call myService.myEcho("world")
returning to myCallBack
onException serviceLib.serviceExceptionHandler;
Nach dem Aufruf führt
der Service eine Task aus und antwortet in den meisten Fällen auf den EGL-Laufzeitcode. Der EGL-Laufzeitcode
ruft daraufhin eine Callback-Funktion (Rückruffunktion) auf. Eine Callback-Funktion ist eine Rich-UI-Funktion, die
Sie codieren und in der Anweisung call angeben, die auf den Service zugreift. Der Aufruf durch den
EGL-Laufzeitcode wird als Callback ausgeben bezeichnet. Wenn beim Servicezugriff ein Fehler auftritt
und Sie in der Anweisung call einen Ausnahmebehandlungshandler angegeben haben,
ruft der EGL-Laufzeitcode den Ausnahmebehandlungshandler auf.
Im obigen Beispiel empfängt die
Callback-Funktion myCallBack (nicht gezeigt) den von einem Service zurückgegebenen Text
und fügt diesen zur Laufzeit in die Webseite ein.
Der Zugriff auf Services über Rich UI
umfasst in der Regel die folgenden Schritte:
- Verwenden Sie ein Workbench-Tool, um einen EGL-Schnittstellenabschnitt zu erstellen, der die Serviceoperationen
beschreibt. Dieser Abschnitt gibt für eine bestimmte Operation den Rückgabewert
und die Argumentliste an.
- Erstellen Sie eine Zugriffsvariable, die auf dem Schnittstellenabschnitt basiert.
- Verwenden Sie die Variable in einer call-Anweisung.
Die Anweisung call enthält die Details, die der EGL-Laufzeitcode
benötigt, um einen Callback auszugeben und einen Ausnahmebehandlungshandler zu definieren, der
zur Laufzeit aufgerufen wird, wenn der Aufruf fehlschlägt.
Rich-UI-Proxy
Für den Zugriff auf einen Service verwendet eine Rich-UI-Anwendung
den Rich-UI-Proxy. Der Rich-UI-Proxy ist eine Laufzeitsoftware, die zusammen mit Ihrem Code auf einem
mit Java™ EE kompatiblen Anwendungsserver installiert
wird.
Der
EGL-Rich-UI-Proxy ist eine Laufzeitsoftware, die zusammen mit Ihrem
Rich-UI-Code installiert und auf einem mit Java EE kompatiblen
Anwendungsserver ausgeführt wird. Der Proxy wickelt die Kommunikation zwischen der Anwendung und allen
Services ab, auf die die Anwendung zugreift:
- Bei der Anforderung eines SOAP-Service empfängt der Proxy die Anforderung von der Anwendung, liest eine
WSDL-Datei auf dem Server, formatiert eine SOAP-Nachricht für die Übertragung an den Service und sendet eine
Serviceanforderung.
Wenn der Service eine Antwort sendet, formatiert der Proxy die Antwort für die
Callback-Funktion neu und sendet die Antwort an die Anwendung.
- Wird ein anderer Servicetyp angefordert, ist der Prozess ähnlich, aber
einfacher. Eine WSDL-Datei ist nicht beteiligt.
Die Rich-UI-Anwendung verwendet
den EGL-Rich-UI-Proxy für den Zugriff auf jeden aufgerufenen Service. Dazu gehören auch die Services, die sich
auf demselben Server befinden.
Services, auf die ein Zugriff über Rich UI möglich ist
Die Rich-UI-Anwendung
kann auf die folgenden Services zugreifen:
- Web-Service, einschließlich eines EGL-REST-RPC-Service
- EGL-Service, der als dedizierter Service implementiert wird,
der für andere Logik in der Rich-UI-Anwendung zur Verfügung steht.
Dieser Service ist für den Rich-UI-Proxy ein lokaler Service, der auf dem Anwendungsserver ausgeführt
wird, der die Rich-UI-Anwendung übertragen hat. Beim Zugriff auf einen dedizierten Service muss
der Serviceabschnitt als Basis für die Servicezugriffsvariable verwendet werden. Ein Schnittstellenabschnitt
kann nicht verwendet werden.
Mit dem dedizierten Service können Tasks ausgeführt werden, die von anderen
EGL-generierten Java-Services ausgeführt werden, z. B. auf eine Datenbank,
ein Dateisystem oder ein lokales IBM® i-Serviceprogramm
zugreifen. Der dedizierte Service steht jedoch nur dann für anderen Code zur Verfügung, wenn er
als SOAP- oder EGL-REST-RPC-Service erneut implementiert wird.
Die folgenden allgemeinen
Einschränkungen müssen beachtet werden: Wenn der Code eine HTTP-Sitzung erfordert, ist der Zugriff
auf diesen Code nur dann möglich, wenn er auf einem Anwendungsserver ausgeführt
wird. Wenn ein dedizierter Service j2eeLib-Bibliotheksfunktionen aufruft, können Sie nur dann über
die Registerkarte 'Vorschau' auf den Service zugreifen, wenn der Service auf einem Testserver implementiert
ist. Wenn die Entwicklung so gut wie abgeschlossen ist, können Sie die Deklaration der Servicezugriffsvariablen
ändern und anschließend den gesamten EGL-generierten Code implementieren:
- Die anfängliche Variablendeklaration könnte wie folgt lauten:
myService MyServicePart {@BindService{}};
- Kann ersetzt werden durch:
myService MyServicePart{@dedicatedService};