Hi All,
 
These days I am working on a message bridge that connect two JMS domains. So from that experience, I also believe that we should not keep the state inside the synapse for messages. This will bind us to use a single synapse instance for related messages and we will not be able to handle them using several synapse instances.( may be connected through some message queue)

Thanks,
- Jaliya
----- Original Message -----
Sent: Thursday, February 02, 2006 7:59 AM
Subject: Re: Proposal to keep states

Saminda

I am very against us doing this.

The aim of Synapse is to be widely deployed and clustered. This design assumes that the messages come back to a single synapse server and also that the server has not failed in the meantime.

There are two solutions to this problem. The first solution is to use the WS-Addressing Reference parameters to include as much information as required in the message itself.

The second solution is to use a process (BPEL) server.

I strongly support us keeping Synapse stateless for very high performance, clustering and failover.

Paul

On 2/2/06, Saminda Abeyruwan < [EMAIL PROTECTED]> wrote:

Hi Devs,

Problem : Synapse needs a way to keep track of status of the incoming message.

Use case: Assume a message comes (IN-Path) to Synapse and it is subjected to few rules such as route to the destination1, once the response returns to Synapse (if), again the message process through Synapse and hit another rule to say route the message destination2. Once the response return (hopfully) we need to send THIS processed response message again to to the initiator of the original message (the Client).

Now during the above process we "new" SynaspeMessages and MessageContext in Synapse, thus, this will restrain the ability of keeping the state of THIS message.

As there is no such mechanism involved, there is no way Synapse to know whether to trigger transport level details of Axis2 such as choosing between 200 OK and 202 OK.

Proposal

At present there is only ONE SynapseEnvironment available for every message that is coming into Synapse. (This is analogues to Axis2's ConfigurationContext)

According to the architecture <send/> will create a new SynapseMessage when the response comes to a outbound message. So it it obvious that <send/> is the last "Mediator" that should be in the mediator chain, before newing another SynapseMessage to inject the response back into Synapse. This is equivalent of treating this message as a fresh message entering into Synapse. yet, this is the response to the original me

So, what we need per IN-Message is another level of abstraction that does not change with newing SynapseMessage. Let's Call this MediationContext.

So when a message enters into Synapse there is only one MediationContext exist for all of this message mutations until the return comes back to SynapseMessageReceiver, to select between 200/202 OK.

So this MediatonContext can be used to keep state across mediators for a given message.


Please see Figure1.

Please be kind enough to express your consensus on prior.

Thank you

Saminda







---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
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

Reply via email to