The access path of Web services is usually specified in WSDL files
as an endpoint address. You can modify the configuration of the attributes
of a Web services connector to change the endpoint address of Web
services.
Invoking the default access path
For JAX-WS,
the endpoint address that is specified in a WSDL file is consumed
at run time; however, for JAX-RPC, the endpoint address is used during
compile time. For Web services runtime to use the endpoint address
that is specified in a WSDL file, do not specify an
endpointAddress attribute
in the definition of the Web services connector. As shown in the following
example definition of a Web services connector, an
endpointAddress attribute
is not specified:
< JaxWsConnector id=”PeopleService”
namespaceUri=http://mock.dallas.com/
serviceName="PeopleServicesService"
portName="PeopleServicesPort"
serviceEndpointInterface="com.dallas.mock.PeopleServicesDelegate"
wsdlUrl="/WEB-INF/wsdl/PeopleServicesService.wsdl"/>
Configuring the Web services endpoint address in a
Web services connector
To override the endpoint address that
is defined in a WSDL file, specify a value for the
endpointAddress attribute
in the Web services connector definition. As shown in the following
example definition of a Web services connector, specifying a value
for the
endpointAddress attribute invokes another
Web services server.
< JaxWsConnector id=”PeopleService”
namespaceUri=http://mock.dallas.com/
serviceName="PeopleServicesService"
portName="PeopleServicesPort"
serviceEndpointInterface="com.dallas.mock.PeopleServicesDelegate"
wsdlUrl="/WEB-INF/wsdl/PeopleServicesService.wsdl"/
endpoint Address=”http://localhost:9080/TestWebservices/PeopleService”>
Defining a relative path for an endpoint address
You
can specify a relative path for the
endpointAddress attribute,
which makes it easier to switch between different Web services servers.
In the following example definition of a Web services connector, the
server1 variable
in the
endpointAddress attribute delegates a Web
services server.
< JaxWsConnector id=”PeopleService”
namespaceUri=http://mock.dallas.com/
serviceName="PeopleServicesService"
portName="PeopleServicesPort"
serviceEndpointInterface="com.dallas.mock.PeopleServicesDelegate"
wsdlUrl="/WEB-INF/wsdl/PeopleServicesService.wsdl"/
endpoint Address=”${server1}/TestWebservices/PeopleService”>
To
ensure that the
server1 variable is understood
at run time, the variable for target Web services server needs to
be resolved to a real URL address during run time. You can configure
a variable resolver implementation class in the
btt.xml file
as shown in the following example:
<kColl id="WebServices">
<field id="VariableResolver"
value="com.ibm.btt.services.ws.endpoint.DefaultVariableResolver"/>
<kColl id="servers">
<!-- Configure server environment info consumed by default variable resolver -->
< field id="server1" value="http://127.0.0.1:9080" >
</kColl>
</kColl>
As shown in
Figure 1, a variable
resolver interface is provided by
WebSphere® Multichannel
Bank Transformation Toolkit. A default
implementation class,
DefaultVariableResolver,
is provided by
WebSphere Multichannel
Bank Transformation Toolkit. You
can implement the
IVariableResolver interface to
define the order in which variables are resolved.
Figure 1. Variable
resolver class hierarchy
The default implementation for a variable resolver uses the
following order: Firstly, it is verified whether there is a
server1 WAS
environment variable. If not, it will check whether the
server1 variable
named is defined in the
btt.xml file. The name
of the variable is replaced with its value during run time. If the
variable cannot be resolved by the variable resolver, the default
endpoint address is used.