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 1: Line 1:
 
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 the access details when you are developing or deploying your application.  
 
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 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. <br><br>'''Note: Aspects of the technology are changing for the better.&nbsp; For details, see [[https://bugs.eclipse.org/bugs/show_bug.cgi?id=369135]].<br>  
+
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. <br><br>'''Note: Aspects of the technology are changing for the better.&nbsp; For details, see [[https://bugs.eclipse.org/bugs/show_bug.cgi?id=369135] Bugzilla 369135].<br>  
  
 
= The typical process  =
 
= The typical process  =

Revision as of 13:18, 29 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 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.

Note: Aspects of the technology are changing for the better.  For details, see [[1] Bugzilla 369135].

The typical process

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 in either of two ways:

  • 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"}};

// another declaration
myService02 MyOtherInterfaceType?{@Resource};

The bindingKey annotation field is optional and defaults to the name of the variable; for example,  myService02 in the preceding code.

Whether you specify the function or annotation:

  • Access to the stored binding occurs at run time, when the generated output invokes code that is equivalent to the SysLib.getResource function.
  • You can explicitly identify an EGL deployment descriptor:
myService MyInterfaceType?;

myService = SysLib.getResource("MyBinding", "MyDD"); 
myService MyInterfaceType?(@Resource{bindingKey = "myBinding",
                                   propertyFileName = "myDD"}};
  • By default, the referenced EGL deployment descriptor is the one named in the following project property: Development Deployment Descriptor.

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:


Back to the top