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
equivalent for accessing a service or database. The typical process
is as follows:
- Write a resource binding in an EGL deployment descriptor.
- 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.
A variable that includes binding detail is called a binding
variable.
- Place 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
SysLib.getResource function,
which can be invoked only inside an EGL function:
myBindingVar HttpRest? = SysLib.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 can declare a variable:
myBindingVar HttpRest?{@Resource{uri="binding:myEntry"}};
The reference to a uri annotation field
is optional and refers by default to a resource binding that has the
same name as the binding variable. For example, the missing value
for the uri field in the preceding annotation is "binding:myBindingVar".
Whether
you specify the
SysLib.getResource function or
Resource annotation,
you can use an extended format ("binding:file:#
entry") to identify
the EGL deployment descriptor that contains the entry. Here is an
example:
myBindingVar HttpRest? = SysLib.getResource("binding:file:myDDFile#myEntry");
// equivalent annotation
myBindingVar HttpRest?(@Resource{uri = "binding:file:myDDFile#myEntry"}};
If
you do not use the extended format, the referenced 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.
For further information
The next topics
give further details: