synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Fremantle <pzf...@gmail.com>
Subject Re: Failover scenario in Synapse - FailoverMediator
Date Tue, 03 Jan 2006 09:48:47 GMT
Folks

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 <samindaa@gmail.com> wrote:
>
> Please see my comment below,
>
> On 1/2/06, Vikas <vikas@infravio.com> 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
paul@wso2.com

"Oxygenating the Web Service Platform", www.wso2.com

Mime
View raw message