Service access in EGL

With EGL, you can access services both in and outside of Rich UI, and you can access services that are written in EGL.

Service access in Rich UI

Service access in Rich UI is always asynchronous, which means that the requester, the Rich UI handler, continues running without waiting for a response from the service. The user can still interact with the user interface while the Rich UI handler waits for the service to respond.

After the invocation, the service does some task and, in most cases, responds to the EGL Runtime. The EGL runtime code then invokes a Rich UI function that you code: a callback function. The invocation by the EGL runtime code is described as issuing a callback.

For example, the following code accesses the implementation that is shown in “Developing Web services":
myService MyServicePart{};
call myService.myEcho("world")
     returning to myCallBack
     onException serviceLib.serviceExceptionHandler;

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.

To access a service, a Rich UI application uses a Rich UI proxy, which is runtime software that is installed with your code on a JEE-compliant application server. For more information, see “EGL Rich UI proxy.”

When you use IBM® Rational® EGL Community Edition, your Rich UI application can access a local EGL service that is dedicated 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. With the local EGL service, you can quickly create a mechanism for accessing a database from your Rich UI application. However, the local EGL service is not available to other code unless you redeploy the service as a SOAP or EGL REST service.

To access a local EGL service:
  1. Create an access variable that is based on the Service part that you code.
  2. Use the variable in a call statement. The call statement includes the details that the EGL runtime needs to issue a callback and to specify an exception handler, which is invoked at run time if the invocation fails.
The process for accessing SOAP, REST, and EGL REST services is similar, but involves creating an EGL Interface part in most cases:
  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 needs to issue a callback and specify an exception handler, which is invoked at run time if the invocation fails.

Service access outside of Rich UI

Service invocation outside of Rich UI is always synchronous, which means that the requester waits for a response from the service.

For example, the following code accesses the implementation that is shown in “Developing Web services":
returnValue String{};
myInterface MyInterfacePart{};

try
   returnValue = myInterface.myEcho("world");

   onException(except AnyException)
      // exception handling
end
Typically, accessing a service outside of Rich UI involves creating an EGL Interface part:
  1. Use a workbench tool to create an EGL Interface part that describes the service operations.
  2. Create an access variable that is based on the Interface part. In this case, you use the variable in a service-invocation statement that is simpler than the call statement. You do not use a callback function either; instead, the service-invocation statement places a returned value into a variable. You can embed the service-invocation statement in a try block, including an exception handler that is invoked at run time if the invocation fails.

When your service accesses a local EGL service, the accessed code is local to the accessing service and does not involve the EGL Rich UI proxy.

Special use of an EGL Service part

To access a service that was written in EGL, you can base the access variable on the EGL Service part. When you use a Service part in this way, only the function parameters and return-value types are meaningful.


Feedback