EDT:Resource Binding Introduction

< EDT wiki home
One of the more elegant aspects of EGL is its use of resource bindings, each of which is a value that describes how to access a service or database. In most cases, you maintain bindings in an EGL deployment descriptor, which is external to your logic. The deployment descriptor provides the access details when you are developing or deploying your application.

This use of the deployment descriptor is safe and flexible. You can change the details stored there and redeploy the code without changing the logic and without spending the time to regenerate output. 

The typical process

The binding mechanism is the same for service and database access. The typical process is as follows:

1. Write a resource binding in an EGL deployment descriptor.
   
2. Relate a variable to the stored resource binding in either of two ways: by invoking the Resources.getResource function or by writing a Resource annotation.  A variable that includes binding detail is called a binding variable.
3. Please the binding variable in an EGL statement. If you are accessing external logic, use the call statement. If you are accessing a database, use one of the statements that read or write data; for example, the add or get statement.

Here is an example use of the Resources.getResource function, which can be invoked only inside an EGL function:

myBindingVar HttpRest? = Resources.getResource("binding:myEntry");

The function call requires a single argument, which identifies an entry in the EGL deployment descriptor.

Here is an example use of the equivalent Resource annotation, which you can specify anywhere that you declare a variable:

myBindingVar HttpRest?{@Resource{uri="binding:myEntry"}};

The uri annotation field is optional and refers by default to a resource binding that has the same name as the variable. For example, the missing value for the uri field in the following annotation is "mybinding:myBindingVar":

myBindingVar HttpRest {@Resource};

Whether you specify the Resources.getResource function or Resource annotation, you can use an extended format ("binding:file:fileName#entry") to identify the EGL deployment descriptor that contains the entry. Here is an example:

myBindingVar HttpRest? = Resources.getResource("binding:file:myDDFIle#myEntry");


// equivalent annotation
myBindingVar HttpRest?{@Resource{uri = "binding:file:myDDFile#myEntry"}};

If you do not use the extended format, the reference EGL deployment descriptor is as follows:

• At development time, the code is referencing the development deployment descriptor. That descriptor is the one that is identified in the following project property: Development Deployment Descriptor. 
• At deployment time, the code is referencing the deployment descriptor that you deploy.

Bindings in your code

A resource binding includes a series of fields that are characteristic of a particular type of binding. For example, a REST service binding has fields that are different from those in an SQL database binding. The existence of binding types means that you can go beyond the typical process described earlier:

• You might define a variable that is of the appropriate binding type. You can assign field values to that variable and use the variable for resource access. In this case, the resource binding is solely in your code.
• In relation to service bindings, you can initialize the variable with values from the EGL deployment descriptor and then update the fields in your code.

The next sections give further details:

• Service bindings
• SQL database bindings

The following topic gives an overview on IBM i support, which also involves resource bindings:

• Support for IBM i