MetaFluent Architecture Overview


At MetaFluent we believe that:

• standards are good for us and good for our customers
• data should adapt to your business, not the other way around
• we should keep life simple for both developers and system administrators
• our products should integrate with existing systems as a matter of course

Read more about our philosophy...

Dynamic Data Virtualization

Applying this philosophy to real business use-cases has resulted in a conceptual architecture that drives all MetaFluent product designs. The primary aim of this patent-pending architecture is to enable standards-based access to virtualized dynamic-data resources, such as messaging systems and real-time data feeds. "Virtualizing dynamic-data resources” means two things:

• Virtualizing transport—i.e., enabling a given API to interact with multiple underlying systems that do not support the API natively

• Virtualizing data—i.e., enabling a given data model & symbology to support multiple data sources that are not provided natively in that model and symbology.

Virtualizing dynamic data resources is analogous to virtualizing hardware resources such as servers, memory, or storage. In both cases, the effect is to greatly increase business flexibility while reducing total cost of ownership. Developers can code without concern for the underlying plumbing, while administrators can quickly deploy and redeploy applications or underlying systems with minimal impact on the business.

Unique Properties of the MetaFluent Architecture

Partial implementations of the dynamic data virtualization concept such as feed handlers, market data platforms, and abstraction APIs have been used in the financial industry for years. What’s innovative about the MetaFluent architecture? Several things:

• The MetaFluent architecture can virtualize as much of the access-protocol stack as an organization wishes. This includes everything a developer codes into his application in order to interact with a dynamic data resource: the API, the symbology, the data structures, and the data semantics. (MetaFluent does not provide the symbologies or data models themselves but rather an efficient means for applying them to a variety of data sources.)

• The MetaFluent architecture supports standard interfaces. The industry seems to overflow with financial-data integration platforms, each offering its own APIs. Every new product means yet another API. MetaFluent took a radically different approach, starting with agreed industry-standard interfaces that are already familiar to developers around the world, such as the JMS specification.

 Conceptual Architecture

• The MetaFluent architecture is very efficient. Virtualization is not free, either in terms of compute resources or administrative resources, so the trick is to provide customers with the most efficient tradeoffs possible. In some cases, that may mean virtualizing at the client through “wrapper libraries”. That is represented in the portion of the diagram where MetaFluent implementations of the standard APIs directly integrate with third-party systems. This can make sense if there is a surplus of desktop resources or if latency is a dominant concern, but it carries a relatively high administrative burden. In other cases, when organizations find it easier to provision and manage resources on the server side, the virtualization logic can be located in a server cluster, which insulates the API from the third-party system (represented in the diagram as the standard API communicating directly with the MetaFluent infrastructure). In addition to supporting both of these topologies, the MetaFluent architecture provides for mixed environments, where some resources are accessed directly while others rely on a middle tier. In this case, MetaFluent orchestration logic routes datastream requests to the appropriate resource based on topic, without the application needing to know anything about the access method.

• The MetaFluent architecture simplifies deployment. The flexibility to tailor how each data resource is virtualized for each user group presents a potentially show-stopping configuration challenge. Indeed, we believe this is one reason no other product offers this kind of flexibility. Nevertheless, MetaFluent’s patent-pending user context framework simplifies management so that users with very different needs can be served from the same infrastructure.


More information on the MetaFluent conceptual architecture and how we put it into practice is available throughout this web site. In particular:

To explore how you might be able to exploit the MetaFluent architecture to solve your business problems, please contact us.