Resource bindings

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. The bindings are maintained 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 then redeploy the code without changing the access logic and without spending the time to regenerate output.

Service bindings

If the purpose of a resource binding is service access, the definition is called a service binding, and the main detail is in one of two formats.
  • If the service is deployed on an application server, you can specify a Universal Resource Identifier (URI), as shown in the following example:
    • http://myserver:8080/myproject/restservices/myservice

    Although you can run the deployed service during an EGL debugging session, the EGL debugger does not step into the service.

  • If the service is available in your workspace and was written in EGL, you can use a workspace URI , which is an identifier that points to a workspace location. Here is an example:
    • workspace://mySourceProject/servicepackage.serviceName

    In this case, an internal Test Server enables you to debug the code, and the URI is useful only at development time. The Test Server is described here: EGL test server.

Database bindings

If the purpose of a resource binding is to specify the connection used for database access, the definition is called a database binding. You can place the binding in the EGL deployment descriptor, but can include the connection information directly in your code.

For further details, see EGL support for relational databases.