Service-location details for web-service access

Although you can place the service-location details of a web service in the requesting source code, the best practice is to place those details in the EGL deployment descriptor.

By placing the details in a deployment descriptor, you have a few potential advantages. For example, if you place details in the deployment descriptor and a detail of the service location changes, these statements are true:

To retest the computer, you can do less work compared to the work needed to handle a code change
The requester is not offline as long as would otherwise be necessary
Errors are not added to the source code, as might occur from even small changes to the logic

When you place details in the EGL deployment descriptor, you specify the @BindService complex property when you declare a service-access variable. That property refers to an entry in the EGL deployment description, specifically, to an entry in the service-client bindings section of the EGL deployment descriptor.

The entry in the service bindings section behaves differently depending on the type of service that you access:

If you access a SOAP service, the entry in the service bindings section refers to a WSDL file that in turn refers to the service location. If a service location changes, you do not need to change the code or deployment descriptor. You must change the WSDL file only.
If you access any other type of service, the entry in the service bindings section refers to the service itself.

When you access a third-party REST service, you must distinguish between the following types of information:

Base URI, which is a set of high-level qualifiers for the service location. For example: www.example.com/myproject/restservices/employee. Specify the base URI in one of these locations:
- The deployment descriptor
- The service bindings section
- The statement that declares the service-access variable
URI template, which is a set of lower-level qualifiers that are concatenated to the base URI. Those details are specific to an operation, such as GET, and you specify them in the Interface part that is used to create a service-access variable.
If you change the URI template, you must change it in the Interface part and redeploy the code in the workbench. You cannot include the template in a runtime configuration file because the template generally includes values that are set at run time.

You can access a third-party REST service by specifying all the details in either the base URI or a URI template.