Service access in Rich UI

Service access in an EGL Rich UI handler or library is always asynchronous: the requester continues running without waiting for a response from the service. The user can still interact with the user interface while the requester waits for the service to respond.

The following code accesses the implementation that is shown in EGL support for SOA:
myService MyServicePart{};
call myService.myEcho("world")
     returning to myCallBack
     onException serviceLib.serviceExceptionHandler;

After the invocation, the service does a task and, in most cases, responds to the EGL runtime code. The EGL runtime code then invokes a callback function. A callback function is a Rich UI function that you code and that you specify in the call statement that accesses the service. The invocation by the EGL runtime code is described as issuing a callback. If an error occurs during service access and you have specified an exception handler in the call statement, the EGL runtime code invokes the exception handler.

In the previous example, the myCallBack callback function (not shown) receives the text that is returned from a service and places it on the web page at run time.

Typically, the process for accessing services from Rich UI is as follows:
  1. Use a workbench tool to create an EGL Interface part that describes the service operations. For a given operation, the part identifies the return value and argument list.
  2. Create an access variable that is based on the Interface part.
  3. Use the variable in a call statement. The call statement includes the details that the EGL runtime code needs in order to issue a callback and specify an exception handler, which is invoked at run time if the invocation fails.

Rich UI proxy

To access a service, a Rich UI application uses the Rich UI proxy. The Rich UI proxy is runtime software that is installed with your code on an application server that is compliant with Java™ EE.

The EGL Rich UI proxy is runtime software that is installed with your Rich UI code, which runs on an application server that is compliant with Java™ EE. The proxy handles the communication between the application and any services that are accessed by the application:
  • When a SOAP service is requested, the proxy receives the request from the application, reads a WSDL file on the server, formats a SOAP message for transmission to the service, and sends a service request. When the service sends a response, the proxy reformats that response for use in the callback function and sends the response to the application.
  • When another kind of service is requested, the process is similar but simpler. No WSDL file is involved.

The Rich UI application uses the EGL Rich UI proxy to access every invoked service, even services that are on the same server.

Services that can be accessed from Rich UI

Your Rich UI application can access the following kinds of services:
  • A web service, including an EGL REST-RPC service
  • An EGL service that is deployed as a dedicated service, which is available to the other logic in the Rich UI application. That service is local to the Rich UI proxy and runs in the application server that transmitted the Rich UI application. When you access a dedicated service, you must use the Service part as the basis of the service-access variable. You cannot use an Interface part.

    You can use the dedicated service to do tasks that other EGL-generated Java™ services can do, such as accessing a database, a file system, or a local IBM® i service program. However, the dedicated service is not available to other code unless you redeploy it as a SOAP or EGL REST-RPC service.

    Be aware of the following, general restriction: if code requires an HTTP session, you cannot access that code unless it is running on an application server. In particular, if a dedicated service invokes j2eeLib library functions, you can access the service from the Preview tab only if the service is deployed on a test server. When development is all-but complete, you change the service-access variable declaration and then deploy all the EGL-generated code:
    1. The initial variable declaration might be as follows:
      myService MyServicePart {@BindService{}};
    2. Here is the replacement:
      myService MyServicePart{@dedicatedService};