In financial services, particularly around money movement and trading platforms, most things are done asynchronously. Swipe your card at Wal-Mart, its asynchronous. Go to the ATM for some fast cash, its asynchronous. Execute that trade on eTrade, its asynchronous. Go to your nearest branch and deposit a check, clearly asynchronous. In reality, most of us have a synchronous (request/reply) experience with our financial institutions but the implementation behind the experience is most likely asynchronous.
With that in mind, a lot of the focus is the messaging platforms that financial systems depend on. How to scale, how to make them faster, how to make them more stable, etc. The options have been around for a while in the likes of IBM MQ Series, TibcoRv, etc. The main issue with these is that they are proprietary. There is no common wire protocol, API or even a well defined interaction model. As result, we all wrote wrappers to encapsulate the interaction or just dealt with it. So, when posed with the same question in my new role, I ran back to mama per se. However, the constraints were different.
- Strongly prefer Open Source
- Cross language support; Java, C++, Python (No Cobol or Assembly!)
- Extremely low latency
- Flexible & extensible security model
- Open interfaces & wire protocols
Funny part, I remember nearly this exact same conversation with Brian Stevens & Joe Ferrell at RedHat a few years back during an executive briefing. So, guess its come full circle that I would be working on Qpid. Or is it deja vu?
No comments:
Post a Comment