EDT:Resource Binding Services

If the purpose of a resource binding is service access, the definition is called a service binding, and the main detail is in one of three formats:

• If the service is deployed on an application server, you can specify a Universal Resource Identifier (URI). The URI begins with the http: or https: prefix (not shown) and continues with a string like this one:

  //myserver:8080/myproject/restservices/myService

Although you can run the deployed service during an EGL debugging session, the EGL debugger does not step into the service.

• If the service is available in your workspace and was written in EGL, you can use a workspace URI, which is an identifier that points to a workspace location. Here is an example:

  workspace://mySourceProject/servicepackage.myService

In this case, the URI is useful only at development time, and an internal Test Server enables you to debug the code.

• If a Rich UI application includes a Service type that will be deployed as a dedicated service, an Internal Test Server enables you to debug the code. In this case, the EGL deployment descriptor is never used. The only binding detail is the DedicatedService annotation, which is part of the service-access variable declaration. 
  
  If a Service part named MyServiceType is a dedicated service, the declaration might be as follows:

  myService MyServiceType {@DedicatedService}

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: http://www.eclipse.org/edt/papers/topics/egl_soa_overview.html. 

To define a service binding in the EGL deployment descriptor, do as follows:

• In an EGL project, expand the EGLSource folder and double-click the deployment descriptor, which has the file extension .egldd.  
• Click the Resource Bindings tab. The Resource Bindings Configuraton page is displayed.
• Click Add and select REST Service Binding. The Add a Resource Binding page is displayed, as shown here:
  

• In the topmost field, specify the binding name. You can reference that name in your code, whether in a Resource annotation or in a statement that invokes the SysLib.getResource function.
• In the Base URI field, specify a URI, which might be a workspace URI:
  • If you are accessing an EGL REST-RPC service, specify the complete URI.
  • If you are accessing a third-party REST service, you might decide to include only high-level details and to supplement them with values that are stored in an Interface type. For specifics, see the following help topic: "Creating an Interface part to access a REST service."
• The sessionCookieID field is not in use.

You are defining a service binding for a Service type in your workspace. To access that type, you must ensure that the service will be deployed: 

• Switch to the Service Deployment tab. If the service is not already listed, click Add. The Add Web Services page is displayed.

 

• Highlight the Service type of interest, click Add, and click Finish. The Web Service Deployment tab is re-displayed with the new detail.

• To save the deployment descriptor, click Ctrl-S.
  

Accessing a service binding in code

You can bind and rebind a service-access variable, as shown here:

myService MyInterfacePart?;
myService = SysLib.getResource("MyEnglishBinding");

     /* here, you can access the service operations.        */

myService = SysLib.getResource("MyFrenchBinding");

     /* here, you can access the operations of a different 
        but similarly structured service.                   */

Retrieving a service binding and updating it in code

Here is example code, which prepares a variable that is later used to invoke a third-party REST service:

myService IMyService?; 
myBinding HttpRest{@Resource};
myBinding.request.encoding] = Encoding.json;
myService = servicelib.completeBind(myService, myBinding);

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
   /GetWeatherByZipCode?zipCode=27709.
   
2. Accesses a new instance of an HTTPRest object.
   
   That object provides a higher-level URI such as www.example.com/myproject/restservices/weather_service.
   
   In this case, the object contains details that are retrieved from a service binding. If you do not specify a bindingKey annotation field, the name of the service binding is assumed to be the name of the variable; in this case, myBinding.
   
3. Adds detail to the HTTPRest object; for example, to ensure that data is transferred to and from the service in JSON format.
   
4. Invokes the ServiceLib.completeBind function so that the variable references the HTTPRest object.

 

♦ Next:  Database bindings

♦ Previous:  Resource binding introduction