Guys, here are the development plans for the otfeed adapter.
Feel free to comment, discuss, or suggest other features.
1. Internal: Transition to apache.mina transport layer, instead of java sockets. Advantage: highly scalable transport, some code simplifications (delegate all thread management to the apache.mina core). Disadvantage: jar size will get extra 2M.
2. Add a JMS-powered version of the adapter. Not sure if its gonna be an adapter on top of org.otfeed, or fork, or org.otfeed split into smaller components that are hooked together via JMS queues.
There seem to be an interest in a version of org.otfeed runnable inside application containers. Hence the desire to get rid of custom thread management and use components present in enterprise environment. The challenge is to keep the driver simple and usable outside of containers. There are no plans to change user-visible api of the driver.
-Mike
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
2) Maybe better to use AMQP? JMS-AMQP interop seems to be a moving target. JMS seems Java centric with no discernible benefit. Perhaps just provide a method that builds an AMQP body containing the OT message string and leave the usre to chose what and how the client creates+binds their queue to the broker/exchange?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the suggestion. Interesting idea. In a sense that so far org.otfeed was considered to be just a java api. Making it a bridge to the language-neutral protocol is interesting..
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Guys, here are the development plans for the otfeed adapter.
Feel free to comment, discuss, or suggest other features.
1. Internal: Transition to apache.mina transport layer, instead of java sockets. Advantage: highly scalable transport, some code simplifications (delegate all thread management to the apache.mina core). Disadvantage: jar size will get extra 2M.
2. Add a JMS-powered version of the adapter. Not sure if its gonna be an adapter on top of org.otfeed, or fork, or org.otfeed split into smaller components that are hooked together via JMS queues.
There seem to be an interest in a version of org.otfeed runnable inside application containers. Hence the desire to get rid of custom thread management and use components present in enterprise environment. The challenge is to keep the driver simple and usable outside of containers. There are no plans to change user-visible api of the driver.
-Mike
My 2c..
2) Maybe better to use AMQP? JMS-AMQP interop seems to be a moving target. JMS seems Java centric with no discernible benefit. Perhaps just provide a method that builds an AMQP body containing the OT message string and leave the usre to chose what and how the client creates+binds their queue to the broker/exchange?
Just to clarify.... I use the terms 'broker/exchage' in the sense of AMQP not the sense of stock, e.g not stock broker/stock exchange :)
Thanks for the suggestion. Interesting idea. In a sense that so far org.otfeed was considered to be just a java api. Making it a bridge to the language-neutral protocol is interesting..