You
can place the service-location details of a Web service
in the requesting source code, but 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 service-location detail changes:
- To retest
the computer, you need to do a small amount of work
compared to the work needed to handle a code change
- The requester
is not offline as long as would otherwise be necessary
- Errors
will not be 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.
Note these details about the different kinds of service access:
- If you access a SOAP service, the entry in the service-client
bindings section refers to a WSDL file that in turn refers to the
service location. If a service location changes, no change to the
code or deployment descriptor is necessary. You need to change the
WSDL file only.
- If you access any other kind of service, the
entry in the service-client
bindings section refers to the service itself.
When
you access a third-party REST service, you must distinguish
between the following kinds of information: