Skip to main content

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.

Jump to: navigation, search

Difference between revisions of "EDT:Resource Binding Introduction"

Line 23: Line 23:
 
The next sections give further details on all these capabilities:  
 
The next sections give further details on all these capabilities:  
  
*[[Resource_Binding_Services] Service bindings]]  
+
*[[Resource_Binding_Services]] Service bindings]  
 
*[http://wiki.eclipse.org/EDT:Resource_Binding_Databases Database bindings]
 
*[http://wiki.eclipse.org/EDT:Resource_Binding_Databases Database bindings]
  

Revision as of 21:51, 22 January 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 and provides 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 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 as follows:

  • 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("MyBinding"); 

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

myService MyInterfaceType?{@Resource{bindingKey = "myBinding"}};

In either case, access to the stored binding occurs at run time, when the generated output invokes code that is equivalent to the EGL SysLib.getResource function.

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 a 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 on all these capabilities:


 

 

[[Category: EDT]]

Back to the top