Interface classifier overview

The capabilities of the Interface classifier are made available when you code a Interface type, which has prototypes for some or all of the operations provided by a service. That part is the basis of a service-access variable, which is used in the statement that invokes the service.

A second use of the Interface part is as a design tool.

The Interface type as a custom type

If you accessing a service written in a language other than EGL, you must use an Interface part to declare the service-access variable. If you are accessing a service written in EGL, you can use either an Interface type or the related Service type to declare the variable.

If you are writing an EGL service and want to distribute details to those who are developing a service requester, you might distribute an Interface type to avoid disclosing the logic inside the service:
  • You might want to hide the source code from developers outside of your organization. In particular, you might ship EGL Interface parts to customers, along with the Java classes that were generated from the Service type.
  • You might want to reduce complexity. The Interface type helps developers focus on the service operations rather than on the internal logic.
Here is an example Interface type, which is based on the service shown in “The Service classifier”:
Interface IMyService
   Function calculate(theList INT[] IN) 
            returns(BIN (4,2));

   // other function prototypes are here
end
Here is the declaration of the service-access variable:
myServiceVariable IMyService;

In this case, you also must declare a variable that is based on BIN (4,2), which is the return type.

Two cases apply:
  • If you are writing EGL code to be generated into Java, the service invocation is synchronous, which means that the invoking logic waits for the service to return control. Here is the code that sets up and fulfills the invocation:
    average BIN(4,2);
    average = myServiceVariable.calculate([90, 70, 80]);
  • If you are writing EGL code to be generated to JavaScript, the service invocation is asynchronous, which means that the invoking logic continues running. The EGL runtime code directs the service-response data to one of the following functions:
    • A callback function, which is a function that is coded to receive the return value after a successful invocation.
    • An exception handler, which is a function that is coded to receive error details after a failed invocation.
    Here is the code that invokes the service asynchronously from a Rich UI handler:
       call myServiceVariable.calculate([90, 70, 80])
          returning to myCallbackFunction 
                       onException ServiceLib.serviceExceptionHandler;

A service-access variable is tied to a service binding, which is a definition that identifies the service location and access protocol. The binding can be in the deployment descriptor, and that practice provides the greatest flexibility. If you are invoking a web service, you can set the binding in the code itself.

An Interface type does not include a stereotype.

The Interface type as a design tool

You can also use an Interface type to describe the functionality that you want to see coded in an EGL service. After the Interface type is complete, you or others can code the service, which is said to implement the interface. The meaning of that phrase is that the service contains every function described in the Interface type. The type provides a kind of contract that the service must fulfill.

Using an Interface type as a design tool has the following benefits:
  • Helps developers and business analysts think clearly about what operations are needed in a service before service development begins.
  • Helps developers write the service-access code while the service is under development.