There is another option:
Instead of having the failover mediator do the work, we could update the send mediator to do this.
Then we add a failover mediator and this simply adds the potential addresses of endpoints into the context.
If there is one address only, then the send mediator behaves like now. If there are extra addresses in the context then the send mediator does the failover.
Paul
On 1/3/06,
Saminda Abeyruwan <[EMAIL PROTECTED]> wrote:
Please see my comment below,On 1/2/06, Vikas < [EMAIL PROTECTED]> wrote:Hi,I was trying to make a failover mediator up and running, here is a description of the stuff:* Failover Scenario-----------------------------Say a service, http://stockquotes.com has http://stockquotesbackup1.com and http://stockquotesbackup2.com as backups in case it goes down or fails.So if a request comes in for stockquotes, then the service http://stockquotes.com is called, if the reply is a fault then http://stockquotesbackup1.com is invoked. If it also returns a problem then http://stockquotesbackup2.com is called. In case the last service also returns a fault, the response sent to the consumer is a fault.
+1
*The need---------------For failover to be performed by a mediator(assuming it has all the related data, like the locations of the failover/backup services) it would need the original request that came to it.*The difficulty--------------------The message receiver [the default one in Axis2, used to send requests to the native services/Endpoints], takes the request SynapseMessage, invokes the native service, gets the reply message (assuming its a In-Out case). It then goes on to replace the request message's content with that of the reply message, hence the original request is lost. If the first service fails then the service invoked after it never gets the request message but only the fault message.
Actually, once send() call, response soap envelope doesn't override the request Soap envelope. We create a new MessageContext and copy the necessary properties with and set the response soap envelope.
Since you need a the original soap message, the way i see is it as follows.
If you use <servicemediator/> you will get access to SynapseEnvironment impl via EnviromentAware in your mediator. Using a private property you can hold the original soap message in the SynapseEnvironment.
Once the message invoked and the corresponding server fails, again your rule hit some mediator to do the fail over to another server. Again if this mediator implements EnvironmentAware you can access the SynapseEnvironement impl. So you have you original soap message with your private property, and then do the fail over.
*The way-out--------------------* Writing custom MessageReceiver for failover - This is highly AXIS2 based. In case we want to hide our axis2 environment and give users a complete Synapse Experience, this would be the least bit appreciative. Moreover, a mediator writer having to work with MessageReceivers sounds no good.This would be the safest option, to use a receiver which will fit the need. But is it feasible and fits into the architecture, i.e. having different message receivers for different end points.
AFAIKS prior is necessary. Another possibility is to implement the scenario with the notion of service group. Service groups can keep states among services. Anyways if you need to access the original soap message, setting it in the SynapseEnviroment would be more than enough.
* Providing a clone option for the SynapseMessageContext - We can override the clone method, and provide a SynapseMessage getCopy( ) method in the SynapseMessage's implementations. This will be problematic as it could be misused also.
Saminda
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
[EMAIL PROTECTED]
"Oxygenating the Web Service Platform", www.wso2.com
