+1
Content used in the address of a FIX endpoint is not a typical URL, it
contains information to create a FIX session.
A FIX session is an connection between two TCP/IP sockets that transport
messages using asynchronous network I/O. Once a session starts
it keeps live by sending heartbeats followed by session level test
messages between the two FIX engines connected together.
So the URL used in the address of the FIX endpoint is a reference to a
FIX session.
As Asankha mentioned we can used the slimier approach to like the JMS
impl, how it mapped it to a FIX impl is as follows.
- Define all the synapse.initiator (that connect to the acceptor
endpoint) FIX session inside the synapse.initiator FIX configuration
file. (identified by the parameter 'transport.fix.InitiatorConfigURL')
- Start the FIX engine for synapse.initiator in the start-up as it does
for synapse.acceptor session(s)
- Keep the created/active sessions in a data structure (identified when
the 'onCreate' callback get fired)
we might have to keep two data structures 1) session string| session
id 2) session id | QFJ session object and do a re-hash
- Use the current FIX URL to send messages
- Check the session availability by using the URL string or create
a new session
- Let the QFJ to dispatch the message using the correct session
Asanka A.
Asankha C. Perera wrote:
Andreas Veithen wrote:
There is an alternative to all this:
1. Create an implementation of the Startup interface together with a
StartupFactory and StartupSerializer.
2. When the init method (defined by ManagedLifecycle) is called on
the Startup (at Synapse startup as the name implies), it gets the
SynapseEnvironment as parameter. From there you can get access to the
SynapseConfiguration and the Axis2 ConfigurationContext (provided
that SYNAPSE-382 is fixed).
3. SynapseConfiguration#getProxyServices gives you the list of
defined proxy services and ProxyService#getTargetEndpoint gives you
the target endpoint.
4. ConfigurationContext#getAxisConfiguration gives you the
AxisConfiguration and from there you can locate a transport sender by
using AxisConfiguration#getTransport(s)(In|Out) (call
get(Reveiver|Sender) on the Transport(In|Out)Description).
This should give you all the information you need to access the
transport and tell it to start the relevant sessions.
But this would make this Synapse specific with a startup class
involvement? Also this will prevent JMX access from starting and
stopping the transports cleanly as the startup is involved.. I think
the transports should be handled behind the transport abstraction,
without mixing it with Synapse.., and this is possible as I
understand, using the same way the JMS sender operates
I discussed this with Asanka A. who raised this original question and
he agreed that what we have for the JMS sender is what they need. I do
not understand FIX or the transport/implementation much, but AFAIK
what they mean as the "URL" here is not what others seems to think..
Asanka A - if you agree with me, could you please reply to this list
if what I suggest is an appropriate approach, else please tell me why
it will not work?
asankha
--
Asankha C. Perera
WSO2 - http://wso2.org
http://esbmagic.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
