Paul Fremantle wrote:
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.
hi,
state information (or pointer to it) can be also encoded in HTTP cookies
(and/or in ordinary SOAP headers or even SOAP body payload - and the
latter is actually used in BPEL to route messages ...).
The second solution is to use a process (BPEL) server.
i think stock BPEL will not be good enough as it can not access SOAP
headers and in particular WSA headers that are used in Synapse for
routing so some kind of extension seems to be needed - maybe a special
partner that exposes whole SOAP envelope? do you know any example of
such "routing enabled" BPEL?
i thought quite a bit about this problem and i am very interested to see
if somebody also looked into it?
I strongly support us keeping Synapse stateless for very high
performance, clustering and failover.
why not to allow some kind of a pluggable way for mediators to have
state injected into them: before "stateful" mediator continues execution
a mediator controller is called for "stateful" mediators to inject state
into them: the simplest for users would be to use continuations (maybe
not in Java but using a scripting engine and resume/suspend script state
including their local stack) or just make it possible to access some
kind of persistent store (database) from a "stateful" mediator ...
on the other hand if it is not possible to do in Synapse (or out of
scope) maybe there should be a (sub)project to do such stateful
WS-router possible (with BPEL, scripting etc.)?
best,
alek
Paul
On 2/2/06, *Saminda Abeyruwan* < [EMAIL PROTECTED]
<mailto:[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]
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
"Oxygenating the Web Service Platform", www.wso2.com <http://www.wso2.com>
--
The best way to predict the future is to invent it - Alan Kay
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
