synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eran Chinthaka <>
Subject Re: Synapse and WSRM
Date Sat, 24 Dec 2005 11:29:03 GMT
Hi Jaliya,

Let me try to answer this.

What if the service is not behind an RM Endpoint Manager. One of the
usages of Synapse, as I think is, it provides the infra-structure for
other web services engines. For example, you can have your Synapse
engine as a proxy for all the web services engine that are inside your
company. And this Synapse engine will provide you QoS services like RM,
security, etc. so that the internal web services engines do not need to
worry about them. To me, this is one of the great features of Synapse.
So I believe Synapse should worry abt it.


Jaliya Ekanayake wrote:

>Hi Paul,
>Please explain why would synapse worry about in-order delivery. If the
>service is behind a RMEndpoint manager then it will handle the INORDER
>It does not matter whether we lose the order in the mediation level.
>Folks At the hackathon we started talking about RM. The problem with
>RM is where the messages have to be delivered inorder. In that case,
>it is quite possible for the current message to be held up. We do not
>have support in Synapse for the current processor to be paused and
>restarted. Its possible we have to add it in the future. But there is
>a simpler option we can try first: The message comes in. We process it
>and it hits the RM processor. The RM processor always finishes this
>"round" of processing (i.e. it returns false). At some point possibly
>now or in the future, the RM processor will re-inject the message. The
>processor will inject the messages inorder (assuming it is configured
>that way). The RM processor can also set some context flag to identify
>that the message has been processed by the reliability. The message
>now starts its second round of processing. It is up to the configurer
>to make the second round do something different and process the
>message correctly. This can be done using a rule that checks for the
>RM context flag we set earlier. So in other words, we are splitting
>the flow into two flows. The first flow is up until the RM processor
>and the second flow starts when the message is delivered inorder. I
>think we can probably hide some of this in future iterations, but I
>believe this is a good starting point. Paul -- Paul Fremantle
>VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
>"Oxygenating the Web Service Platform",

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message