Hi all,
This mail mainly concern on JIRA
{http://issues.apache.org/jira/browse/SYNAPSE-5}, where Synapse
supporting Routing of messages via different transports.
Axis2FlexibleMEPClient is the class that is responsible for
second stage routing of messages in Synapse. Currently the logic in
this class handles only HTTP.
What we need in this arena is to introduce a mechanism to to chose
among existing transport and custom transport to support second phase
routing. Simply speaking Axis2FlexibleMEPClient works as ServiceClient
in Axis2.
To make the learning curve zero and get hold of the wonderful
engineering of Axis2, i would like to propose the following mechanism
to handle Axis2FlexibleMEPClient logic for different transports.
Let's allow a different "repository" (may i call
axis2flexible_mepclient_repository ) to create a ConfigurationContext,
which has to be used in Axis2FlexibleMEPClient.send(MessageContext).
Let's make sure the Axis2.xml containing in that repository doesn't
give provision for engaging "Addressing". If we use standard
ConfigurationContextFactory to create ConfigurationContext
passing "null" as repository, we have no provision of disabling
addressing module engagement. Let's keep the location of this
repository in the main Axis2.xml, where we use to get configuration
information for Synapse. {we already keep the property to hold the
synapse.xml's location}
so main Axis2.xml contains repository as follows ,
<axisconfig name="Axis2Synapse">
...
<axis2flexible_mepclient_repository >client</axis2flexible_mepclient_repository>
...
</axisconfig>
So integrating any transport as easy as Axis2 handle transport and most importantly learning is zero.
If needed addressing, we can pragmatically engage addressing
module. Using prior technique we can directly use transport
configuration via deployment and we can allow Axis2's transport
mechanism to handle the transport functionalities easily.
Please be kind enough to comment on this
Thank you
Saminda
