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"
| (119 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
| − | = | + | <span style="font-size:smaller;">< [[EDT|EDT wiki home]]</span> <br> 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 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.'''<br> ''' | |
| − | + | = 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.<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''. | ||
| + | #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 often 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 IHttp? = Resources.getResource("binding:myEntry"); | ||
| + | </pre> | ||
| + | The call to '''Resources.getResource''' requires a single argument, which identifies an entry in the EGL deployment descriptor. | ||
| − | <br> | + | A simpler option is to use a '''Resource''' annotation when you declare a variable: <br> |
| + | <pre>myBindingVar IHttp?{@Resource{uri="binding:myEntry"}}; | ||
| + | </pre> | ||
| + | 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 <code>"mybinding:myBindingVar"</code>:<br> | ||
| + | <pre>myBindingVar IHttp? {@Resource}; | ||
| + | </pre> | ||
| + | Whether you specify the '''Resources.getResource''' function or '''Resource''' annotation, you can use an extended format (<code>"binding:file:''fileName''#''entry''"</code>) to identify the EGL deployment descriptor that contains the entry. Here is an example: | ||
| + | <pre>myBindingVar IHttp? = Resources.getResource("binding:file:myDDFIle#myEntry"); | ||
| − | |||
| − | < | + | // equivalent annotation |
| + | myBindingVar IHttp?{@Resource{uri = "binding:file:myDDFile#myEntry"}}; | ||
| + | </pre> | ||
| + | If you do not use the extended format, the behavior 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. <br> | ||
| − | + | You might have multiple deployment descriptors; for example, one for a development environment, one for a test environment, and one for production.<br> | |
| − | + | = 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: | |
| − | In the | + | *You might declare 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.<br><br>The next sections give further details: | |
| − | + | ||
| − | + | *[[EDT:Resource Binding Services|Service bindings]] | |
| + | *[[EDT:Resource Binding Databases|SQL database bindings]] | ||
| − | + | The following topic gives an overview on IBM i support, which also involves resource bindings: | |
| − | [[ | + | *[[EDT:Support for IBM i|Support for IBM i]] |
| − | + | <br> <br> | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
Latest revision as of 10:26, 27 August 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 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 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 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 use 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 variable. For example, the missing value for the uri field in the following annotation is "mybinding: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 behavior 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 declare 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.
The next sections give further details:
The following topic gives an overview on IBM i support, which also involves resource bindings: