Rogue Wave banner
Previous fileTop of DocumentContentsIndex pageNext file
HydraExpress Web Service Development Guide
Rogue Wave web site:  Home Page  |  Main Documentation Page

11.5 Making Transports Dynamic

There are two senses in which a transport can be dynamic:

11.5.1 Selectable Transports

The transports and listeners defined in the transport configuration files are all identified by a name. Either the client or the server (when sending notifications or solicit messages) can select by name the transport to be used to send a message.

Let's consider the following scenario:

Let's suppose that the name of this service is GetQuotes and that it is provided by a company called A2Z Incorporated. The code below shows the code in the client implementation that sends off a purchase order for quotation.

//1Calls some method that creates a PurchaseOrder object from the items that need to be ordered from the company named in the parameter.
//2Adds SOAP header elements specifying that notification should be sent by email and the email address to send it to.
//3Invokes the client proxy sendForQuote() one-way operation method.
//4Resets the default transport to the HTTPS transport.
//5Sets the location property in the new transport.
//6Creates a proxy correctly set up to use HTTPS to send a purchase order to the location for the A2Z incorporated server.
//7Invokes the service operation method for sending a purchase order for quote.

On the server side, the implementation decides based on the SOAP header value how to send the notification to the client.

//1Sends the incoming purchase order to a method that returns a quote.
//2Tests how the reply is to be sent.
//3For email, knows to obtain the SOAP header value with the email address.
//4Creates a transport object that sends messages by SMTP.
//5Sets the email transport email-address property to the email address of the company requesting the quote.
//6Obtains an SMTP-enabled proxy.
//7Returns the quote via email.

11.5.2 Interchangeable Transports

Defining named transports in the transport configuration files allows you to make a service independent of the transport it uses. 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 server-transports.xml and client-transports.xml, you could do this:

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:

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:

There are a couple more details to completing such a switchover:

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.



Previous fileTop of DocumentContentsIndex pageNext file

© Copyright Rogue Wave Software, Inc. All Rights Reserved. All Rights Reserved. Rogue Wave is a registered trademark of Rogue Wave Software, Inc. in the United States and other countries. HydraExpress is a trademark of Rogue Wave Software, Inc. All other trademarks are the property of their respective owners.
Contact Rogue Wave about documentation or support issues.