|
Hi,
Comments inline.
----- Original Message -----
Sent: Tuesday, January 03, 2006 3:18
PM
Subject: Re: Failover scenario in Synapse
- FailoverMediator
Folks
There is another option:
Instead of having the
failover mediator do the work, we could update the send mediator to do this.
This would make the sendMediator
too bulky. What if we introduce new logic for load-balancing, we modify
the sendMediator again??
Wouldn't it be good to have every
mediator as an independent, complete entity.
Then we add a
failover mediator and this simply adds the potential addresses of endpoints
into the context.
So this would push the core failover logic and error
evaluation to sendMediator.
sendMediator becomes mandatory, tying up the
user.
Thanks,
~Vikas
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
-----------------------------
+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
|
