olivier deheurles

My-channels is currently working on version 6 of Nirvana which should be released end Q1/beginning Q2. I’m going to quickly run through the new features:

Direct Data Delivery

Direct Data Delivery (DDD) is the main new addition to the product, it is a new message delivery paradigm.

Before starting, a bit of background: as you may know Nirvana is used by several banks within their SDP (Single Dealer Platform). What is a SDP you may ask? Most of the financial institutions offer to their clients trading applications available on the Web, generally via a Rich Internet Application (Silverlight, Flex, HTML, etc.) or a Rich Client (Java, .NET). Clients can see bank’s prices and trade in real-time. In these environments you have pretty serious requirements for messaging: you need to:

• push prices over internet (HTTP generally mandatory to cross firewalls and proxies) to clients,
• have guaranteed message delivery for trade execution and order management.

Nirvana covers these requirements but it is still challenging to design and implement the price distribution.

Why?

• because prices are generally distributed by tier levels associated to client groups or even with specific price per client. Mapping this distribution topology to JMS Topics (called Channels in Nirvana) is not always easy: if a client can only see one level of tiering you need to make sure he can’t see other levels by defining properly Channels granularity and ACLs.
• you may have to dynamically create channels or queues at runtime, this requires Nirvana admin API, adding a bit of complexity in the system.
• to summarize the JMS model fits pretty well when you need to communicate between server side applications in LAN or WAN. You just have to define a static Channel/Queue schema with static ACLs. But when you are dealing with external users it’s different: you have to grant them ACLs dynamically when they are authenticating.

Direct Data Delivery (DDD) is going to be very useful for these kind of scenarios, let me explain how it works: when the client API connects to the realm it can choose to subscribe to a Data Stream; clients can have only one Data Stream per active Nirvana session. On publisher side you can create, with required ACLs, an other type of resource called Data Group and associate different clients data streams with these data groups. You can then publish messages to a data group and Nirvana will automatically deliver them to clients contained within the group.

How does it helps in the SDP scenario?

• no need to create dynamically channels with the Admin API: data groups can be created dynamically with the Nirvana client API,
• client-side implementation is simplified: you no longer have to subscribe to the different channels used for price distribution, every thing can be managed server-side securely.
• it’s very easy to change client’s from one tiering group to another: remove it’s data stream from one data group and add it to an other one
• DDD will support all the useful features required to distribute price efficiently: last tick cache with delta delivery enabled (snapshot + partial updates) and conflation

API Batching

The client API now provides batching for find and find + subscribes to channels. Very useful again with client scenarios (latency is higher over internet than in LAN so batching is always helpful).

A new .NET API with RX Extensions

Nirvana is a Java product and the .NET API has been designed based on the Java API, so it looks a bit ‘”Java” from the eyes of a .NET developer ;-)

The new .NET API has been redesigned to provide a better experience for .NET developers and also provides access to the DDD and batching functionalities.

On top of that you can plug Rx (Microsoft Reactive Extensions) to get Nirvana event streams exposed as IObservable. I’m not going to explain here what is Rx, you can find lots of information on the DevLabs web site, on the forum or for instance on blogs of some of my mates here and here.

Stay tuned…