So yes I agree that BPEL may not be the best/only approach. I guess my point is that I think there is value in separating a runtime which is stateless from one which is stateful.
If we encode all the "per message" state into each message (cookie or WS-A), then Synapse can do everything required without losing scalability. For example, the return message can be handled by a different JVM than the request message without any requirement to share state across the two JVMs.
The stateful model where I keep state *related to a message* between interactions is harder. It requires a complex infrastructure to allow the session data to be copied across the cluster. Typically solutions use a model like Tangosol or JGroups to do this, but to make the performance scale linearly as you add machines to the cluster is almost impossible.
So I strongly approve of us doing the model where the state required is added into the WS-A headers.
There is also work going on in Axis2 to address the clustered sessions, but I think we should target a separate process manager or stateful orchestration bus as a distinct second step.
Paul
On 2/2/06, Aleksander Slominski <[EMAIL PROTECTED]> wrote:
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]
--
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
