Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "EDT:Resource Binding Introduction"
| Line 9: | Line 9: | ||
#Write a resource binding in an EGL deployment descriptor.<br> | #Write a resource binding in an EGL deployment descriptor.<br> | ||
#Relate a variable to the stored resource binding. You relate the two either by invoking the <span style="font-weight: bold;">Resources</span>'''.getResource''' function or by writing a '''Resource''' annotation. A variable that includes binding detail is called a ''binding variable''. | #Relate a variable to the stored resource binding. You relate the two either by invoking the <span style="font-weight: bold;">Resources</span>'''.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, use one of the statements that read or write data; for example, the '''add''' or '''get''' statement. | + | #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, you 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 typically fulfill a two-step process: declare a binding variable and include it in an action statement. <br><br> | + | The essential point is that when you are writing your logic, you typically fulfill a two-step process: declare a binding variable and include it in an action statement. <br><br>When you declare a binding variable, you might use the '''Resources.getResource''' function, which can be invoked only inside an EGL function: |
<pre>myBindingVar HttpRest? = Resources.getResource("binding:myEntry"); | <pre>myBindingVar HttpRest? = Resources.getResource("binding:myEntry"); | ||
</pre> | </pre> | ||
The function call requires a single argument, which identifies an entry in the EGL deployment descriptor. | The function call requires a single argument, which identifies an entry in the EGL deployment descriptor. | ||
| − | + | A simpler declaration uses a '''Resource''' annotation, which you can specify anywhere that you declare a variable: <br> | |
<pre>myBindingVar HttpRest?{@Resource{uri="binding:myEntry"}}; | <pre>myBindingVar HttpRest?{@Resource{uri="binding:myEntry"}}; | ||
</pre> | </pre> | ||
| Line 34: | Line 34: | ||
*At deployment time, the code is referencing the deployment descriptor that you deploy. <br> | *At deployment time, the code is referencing the deployment descriptor that you deploy. <br> | ||
| − | You might use multiple deployment descriptors; for example, one for a development environment, one for a test environment, and one for production.<br> | + | You might use multiple deployment descriptors; for example, one for a development environment, one for a test environment, and one for production.<br> |
= Bindings in your code = | = Bindings in your code = | ||
Revision as of 12:04, 17 June 2012
< 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. By "redeploy," we mean to re-package the code by fulfilling the EGL deployment step in the Workbench. The redeployment is quick; you neither change the logic nor regenerate much of your output.
The typical process
The binding mechanism is the same for service and database access. 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, you 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 typically 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 HttpRest? = Resources.getResource("binding:myEntry");
The function call requires a single argument, which identifies an entry in the EGL deployment descriptor.
A simpler declaration uses a 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.
You might use 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 next sections give further details:
The following topic gives an overview on IBM i support, which also involves resource bindings: