...ant
Hi Devs,
<syn:enableRM/>
This will enable to engage Sandesha2 (WS-RM) on incoming messages. This Mediator can be used in either message level mediation or service mediation without doing any modification.
This will be subjected to following design constrains.
1. Rule author should not allow to pass each and every message through this mediator. Thus, this mediator should be used with an filter mediator such as <syn:filter/>. So a simple valid Rule configuration would look as follows,
<synapse xmlns="http://ws.apache.org/ns/synapse">
<definitions/>
<proxies/>
<rules>
<filter source="get-property('To')" regex=".*/FOO.*">
<enableRM/>
</filter>
</rules>
</synapse>
Thus the above will make sure that the every message addressed with FOO will be routed through the RM mediator. Thus, all RM related control messages will go through the filter.
2. Synapse hereafter comes as a .MAR. So one can easily deployed it in a existing Axis2 repository and transform it to be a Synapse endpoint. In order to Sandesha2 to work, Synapse user must make sure to include the "RMPhase" is Axis2.xml. RMPhase should be included in inflow, outflow, Infaultflow and Outfaultflow flows respectively.
Mediator and MediatorFactory
As the starting point <syn:enableRM/> does not modify the Sandesha2's default properties, such as AcknowledgementInterval etc. If it need to be changed, WS-Policy could be used.
In rule configuration, <syn:enableRM/> will map to RMMediator and its creator RMMediatorFactory.
RMMediator will create an empty service and an empty operation which will include the EmptyRMMessageReceiver. Sandesha2 will be engaged on this empty service. Thus, all Sandesha2 related control messages and application messages will pass through from here. Once Sandesha2 processing is done, all the application messages will be passed to EmptyRMMessageReceiver. This empty service and operation will be created once and it will be hold in the AxisConfiguration.
When client sends an message with RM enabled, he expects a return within the sequence. So, when a RM Enabled messages pass through the <syn:enableRM/> mediator and when the application message received the EmptyRMMessageReceiver, following should happen,
public class EmptyRMMessageReceiver implements MessageReceiver {
public void receive(MessageContext messageContext) throws AxisFault {
MessageContext synCtx = Axis2MessageContextFinder.getSynapseMessageContext(messageContext);
synCtx.getEnvironment().injectMessage(synCtx);
messageContext.setProperty(
org.apache.synapse.Constants.MESSAGE_RECEIVED_RM_ENGAGED,
Boolean.TRUE);
// rest of Synapse specific code
}
Thus, we allow the application messages to inject into Synapse Environment and apply other rules necessary.
Once EmptyRMMessageReceiver#receive(MessageContext messageContext) returned, the Java returned will be passed back to the RMMediator. At this point if we allow the message to be passed through (returning true) the chain, IMHO that would lead to adverse effects, because the original message has already been subjected to chaining and modification. So RMMediator always return false, this is equivalent to using <syn:drop/> after <syn:enableRM/>.
Thus, using above technique, Synapse will be able to mediate messages in a sequence, using Sandesha2.
Thank you
Saminda
