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:
You can access a third-party REST service by specifying all the
details in either the base URI or a URI template.