Interchangeable Transports and Listeners
Defining named transports or listeners in the transport and listener configuration files allows you to make a service independent of the transport it uses, or a client independent of the listener it uses if it is receiving messages using the notification or solicit-response patterns.
Let’s say, for example, that you maintain a service for providing stock quotes over HTTP. Instead of using the default HTTP transport element in transports.xml and client-transports.xml, you could do this:
 
<rwsf:transports
xmlns:rwsf="http://www.roguewave.com/rwsf/transport">
<rwsf:transport name="HTTP"
uri="http://schemas.xmlsoap.org/soap/http" scheme="http"
default="true" class="rwsf_webservice.createHttpTransport">
<rwsf:property name="connect-timeout" value="60000"/>
<rwsf:property name="submit-timeout" value="60000"/>
<rwsf:property name="reply-timeout" value="60000"/>
</rwsf:transport>
<rwsf:transport name="StockQuoteService"
uri="http://schemas.xmlsoap.org/soap/http" scheme="http"
default="false" class="rwsf_webservice.createHttpTransport">
<rwsf:property name="connect-timeout" value="60000"/>
<rwsf:property name="submit-timeout" value="60000"/>
<rwsf:property name="reply-timeout" value="60000"/>
</rwsf:transport>
You now have two entries with scheme attributes that identify them as HTTP and with class attributes that point to the HydraExpress library HTTP transport object. The HydraExpress default HTTP entry remains the default, but the service implementation code would explicitly use the StockQuoteService transport:
 
rwsf::transport transport =
rwsf::TransportManager::findTransport("StockQuoteService");
StockQuoteServiceProxy proxy =
StockQuoteServiceProxy::make(transport);
If you later decide that HTTP is not providing sufficient performance, you could create a binary transport, point the StockQuoteService transport entries at that transport, and continue on with no need to change or recompile the service code. The entries in the transport configuration files might then look something like this:
 
<rwsf:transport name="StockQuoteService"
uri="http://www.a2zincorported.com/transports/binary/"
scheme="binary" default="true"
class="binarytransport.createBinaryTransport">
<rwsf:property name="some-binary-property" value="whatever"/>
...
</rwsf:transport>
There are a couple more details to completing such a switchover:
*You must restart the server to pick up the new binary transport.
*You must distribute to the clients the modified client-transports.xml file and the new binary transport object.
But the service implementation code would simply use the binary transport now associated with the service.
The next section outlines the process of creating and configuring a custom transport.