synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Fremantle <>
Subject Re: Synapse and WSRM
Date Sat, 24 Dec 2005 11:41:47 GMT

Exactly right. For example, someone may have a PHP web service or PERL web
service that doesn't support WS-Sec, RM, and Addressing. We can put Synapse
in front of the existing service and "terminate" the RM, Sec, and
Addressing and then forward the simple SOAP to the Perl service.


On 12/24/05, Eran Chinthaka <> wrote:
> 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.
> Chinthaka
> 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
> >delivery.
> >It does not matter whether we lose the order in the mediation level.
> >
> >Thanks,
> >
> >Jaliya
> >
> >
> >
> >
> >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:

Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair

"Oxygenating the Web Service Platform",

View raw message