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.
By "redeploy," we mean to fulfill the EGL deployment step to repackage
the code for subsequent distribution. The redeployment is quick; you
neither change the logic nor regenerate your 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. You relate the
two either by invoking the Resources.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 action statement,
which is a statement that interacts with logic that is external to
the code you are writing. If you are accessing external logic, use
the call statement. If you are accessing a database management
system, you use one of the statements that read or write data; for
example, the add or get statement.
The essential point is that when you are writing your
logic, you often fulfill a two-step process: declare a binding variable
and include it in an action statement.
When you declare a binding
variable, you might use the
Resources.getResource function,
which can be invoked only inside an EGL function:
myBindingVar IHttp? = Resources.getResource("binding:myEntry");
The call to Resources.getResource requires
a single argument, which identifies an entry in the EGL deployment
descriptor.
A simpler option is to declare a
Resource annotation
when you declare a variable:
myBindingVar IHttp? {@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 binding variable. For example, the missing value for the
uri field
in the following annotation is
"binding:myBindingVar":
myBindingVar IHttp? {@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 IHttp? = Resources.getResource("binding:file:myDDFile#myEntry");
// equivalent annotation
myBindingVar IHttp? {@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.
You might have multiple deployment descriptors; for example,
one for a development environment, one for a test environment, and
one for production.
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 typical process is unchanged: you declare a binding
variable and include it in an action statement.
For further information
The next topics
give further details: