Service bindings

If the purpose of a resource binding is service access, the definition is called a service binding. The main detail is in one of three categories:

Defining a service binding in the EGL deployment descriptor

At this writing, you can bind to a REST or EGL REST-RPC service. The distinctions among the service types are explained here: Service-oriented architecture (SOA) for EGL developers (http://www.eclipse.org/edt/papers/topics/egl_soa_overview.html).

For details on defining a service binding in the EGL deployment descriptor, see Adding a REST binding to the EGL deployment descriptor.

If you are defining a workspace binding, you must also deploy the Service type. For details, see Adding web-service deployment details to the EGL deployment descriptor.

Retrieving one or another service binding in your code

You can rebind a service-access variable, as shown here:
myService MyInterfaceType?; 

   /* that declaration could have included 
      a Resource annotation, as shown here:

      myService MyInterfaceType? 
         { @Resource {uri="binding:MyGermanBinding"} };    */

if ( ... )
   myService = SysLib.getResource("binding:MyEnglishBinding");
else
   myService = SysLib.getResource("binding:MyFrenchBinding");
end

/* here, you can access the service operations of 
   one or the other service, assuming that the two 
   have similar interfaces.                             */    

Retrieving a service binding and changing it in your code

Here is an example of preparing a variable and then using it to access a third-party REST service:
myService MyServiceType?;
http HttpRest{@Resource{uri="binding:myService"}};        
http.request.encoding = encoding.json;
call myService.myFunction() using http returning to myCallBackFunction
                                       onException myExceptionHandler;
The code acts as follows:
  1. Declares an access variable.

    The declaration references an Interface type that typically includes one or more uriTemplate annotation fields, each of which is a set of lower-level URI qualifiers that are resolved at run time. A resolved template might be this: /GetWeatherByZipCode?zipCode=27709

  2. Accesses a new instance of an HTTPRest object.

    That object provides a higher-level URI such as http://www.example.com/myproject/restservices/weather_service.

    In this case, the object contains details that are retrieved from a service binding in the EGL deployment descriptor. If you do not specify a uri annotation field, the name of the service binding is assumed to be the name of the variable. In the example, the value of the annotation field defaults to "binding:http".

    For details on the HttpRest object, see the help topic named "eglx.http package."

  3. Adds detail to the HTTPRest object; for example, to ensure that data is transferred to and from the service in JSON format.
  4. Uses the HTTPRest object when calling the service.

Creating a service binding in your code

You can create a service binding in your code, in which case the EGL deployment descriptor is not involved. For example, you might substitute the second statement in the following code for the object declaration that was shown in the preceding section:
myService IMyService?; 
http HttpRest = new HttpRest{
   restType = eglx.rest.ServiceType.TrueRest, 
   uri = "www.example.com/myproject/restservices/weather_service"};
myBinding.request.encoding = Encoding.json;
call myService.myFunction() using http returning to myCallBackFunction
                                       onException myExceptionHandler;

For details on the HttpRest object, see the help topic named "eglx.http package."