Revision as of 17:41, 7 February 2012

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 to write a resource binding in an EGL deployment descriptor and to relate a variable to the stored resource binding in either of two ways:

• By invoking the SysLib.getResource function; or
• By writing a Resource annotation.

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

myService MyInterfaceType?;

myService = SysLib.getResource("binding:myBinding");  // .8 syntax

Here is the equivalent annotation, which you can specify anywhere that you can declare a variable:

myService MyInterfaceType?{@Resource{uri="binding:myBinding"}};  // .8 syntax

// another declaration
myService02 MyOtherInterfaceType?{@Resource};

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

Whether you specify the function or annotation:

• Access to the stored binding occurs at run time, when the generated output invokes code that is equivalent to the SysLib.getResource function.
  
• You can explicitly identify an EGL deployment descriptor:

myService MyInterfaceType?;

myService = SysLib.getResource("binding:myDDFile#myBinding");   // .8 syntax

// equivalent annotation
myService MyInterfaceType?(@Resource{uri = "binding:myDDFile#myBinding"}};  // .8 syntax

If you do not identify an EGL deployment descriptor, the referenced file is the one that is currently in use. At development time, the one that is currently in use is identified in the following project property: Development Deployment Descriptor. At deployment time, the referenced deployment descriptor is the one 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
• Database bindings