OK, so the JMS spec makes sense for market data. But is that just for Java? What about non-Java applications? While JMS is, by definition, a Java standard, the fact is that most JMS suppliers offer non-Java bindings. In effect, the JMS messaging model itself has been adopted as a standard by the market.
The MetaFluent Excel Add-In provides macros to publish and subscribe to dynamic data from within Excel. It provides macros for subscription to individual fields, or tables of fields, or fields from collections (multi-stream topics).
The MetaFluent Excel Add-In has a caching layer that implements the Excel RTD Server mechanism. The cache uses the 'C' version of the MetaFluent JMS API. When coupled with the Server-based Provider implementation, Excel is then able to publish-subscribe via the MetaFluent JMS Server and from there interact with external distribution systems such as RMDS.
The modular nature of the MetaFluent Server Framework supports the creation of server applications that combine content modeling capabilities with distribution capabilities to support downstream applications based on a variety of standard APIs and distribution protocols
An essential component of the MetaFluent architectural vision is the ability to flexibly and efficiently give our customers control over the representation of content as seen by applications. In other words, we want our customers to control the data model. To do this the customer needs control over naming (how are items and fields named), scope (what fields are present in the model), content transformation (how do applications see the content), blending of content (where does content come from within the model) and flexible control over data sources (easily switching from one to another). Customizing the data model to fit the business needs of a particular customer requires a very flexible solution based on modular building blocks.
The centerpiece of the MetaFluent Architecture is a modular server framework that allows us to assemble a variety of products satisfying a diverse set of requirements in different deployment scenarios.
In conjunction with the various MetaFluent JMS API implementations, the MetaFluent JMS Server is an extensible, modular JMS Provider based on the MetaFluent Server Framework. The modular architecture means the MetaFluent JMS Server supports a variety of different configurations combining different kinds of functionality so as to efficiently support different business needs - ranging from traditional enterprise application integration to the more specialized functionality of a distribution system for dynamic data.
The MetaFluent architecture embodies a few basic principles. Achieving these is not easy but has big payoffs for customers.
Standards lower development and operating costs, shorten the learning curve, and improve interoperability. If a well-known standard exists that could solve a particular problem, we will use it creatively to make life easier for our customers. An example is our use of JMS as a market data API. Developers with no market data API experience can be subscribing or publishing market data in minutes.
A MetaFluent JMS Application Context defines the resources available to a JMS client application. A Context is a view of the system from an application perspective. The client application specifies which Context it wants using a context identifier (consisting of a name and version number). This is done before creating a JMS Session.
Currently, the MetaFluent JMS Server implementation is a hub-and-spoke architecture that uses TCP/IP as transport and supports clustering with resilient load-balancing. Both MetaFluent JMS Server and the MetaFluent JMS Load-Balancer applications use the modular MetaFluent Server Framework - each application comprising a different set of modules used within the framework.
The MetaFluent architecture includes multiple JMS Providers, each suitable for different types of solutions. Two have been productized so far:
