synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hiranya Jayathilaka" <hiranya...@gmail.com>
Subject Re: Reading Target Address Parameter at Transport Level
Date Tue, 01 Jul 2008 03:09:51 GMT
Hi,

On Tue, Jul 1, 2008 at 12:04 AM, Asanka Abeysinghe <asankaa@wso2.com> wrote:

> +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')


In the current FIX transport impl we don't have to define any
synapse.initiator parameters defined in the FIX URL again in the file
pointed to by the transport.fix.InitiatorConfigURL. What you are suggesting
is to define all the parameters defined in the URL again in the initiator
config file and use that file at the start up to create the session. Am I
correct?

If this is what you mean I'm +1 for the solution. Will require some
documentation changes though.


> - 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 already have the necessary infrastructure for this. So not a problem

Thanks

Best Regards,
Hiranya Jayathilaka


>   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: dev-unsubscribe@synapse.apache.org
> For additional commands, e-mail: dev-help@synapse.apache.org
>
>

Mime
View raw message