MetaFluent JMS Application Contexts

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.

Application Contexts Define Resources

An Application Context governs all aspects of the system on which the client application is explicitly and implicitly dependent.

The attributes of a Context on which an application is likely to have explicit dependencies include:

  • Topic naming - an application needs to formulate topic names in order to subscribe or publish. JMS topic names are a string that can have almost any syntax. MetaFluent doesn't impose an overall topic-naming scheme but rather allows each Contexts to use a scheme that is appropriate for a particular business need. For example, for applications that access market data it might be appropriate for some applications to use Reuters Instrument Codes (RICs) while other applications might most naturally use a CUSIP. It is possible to define a Context that supports one or the other of these, or both at the same time
  • Topic semantics - Applications may use a variety of different topics for different types of data. The nature of the messages received, i.e. the application-level protocol, will vary depending on what the data is. For example, an application might expect to subscribe to dynamic market data on one topic and receive an image followed by updates while another topic might be used to conduct a trade negotiation - a completely different application-level protocol
  • Data model - applications operate on the data (fields) received in the messages from a topic. The field names and the expected data types/values for those fields constitute the data model. This holds true for both subscribers and publishers

Context attributes on which an application is less likely to, and perhaps shouldn't, have explicit dependencies include:

  • Underlying data sources and data transformation - The Context is responsible for the mapping of a topic to the resources that "back" that topic - such as connectivity to external data sources. This mapping also includes the transformation of data from the external source to the data model presented to the application. Conversely, this holds true for data published on the topic - the Context is responsible for the mapping of that data to any external system related to the topic. MetaFluent defines the concepts of both managed and un-managed content
  • Entitlements - the Context is responsible for enforcement of any access control restrictions imposed by external systems
  • Quality-of-Service - the quality-of-service offered by a topic subscription is an important factor in determining the cost of both delivering the data and consuming it. Tick-by-tick data may be difficult to consume in a timely manner. Conflated data is easier on the client but requires a cache of some kind in the server

Application Contexts are Contracts

Those parts of a Context on which an application has explicit dependencies constitute, in effect, an application programming interface, i.e. the application is coded to understand these explicit dependencies. Obviously it is important for system integrity that an application not be subject to incompatible changes, e.g. a change in topic-naming conventions or an incompatible change in the data model. To manage change and application migration, MetaFluent Application Contexts have both a name and a version. When an application specifies a Context it uses a Context identifier that includes a version specification. The Provider analyzes the identifier and provides an implementation that offers the best compatible match with the application. In effect, the context identifier constitutes a contract between the JMS Provider implementation and the application.

Provider Support for Application Contexts

The implementation of the Application Context concept varies from one Provider to another. A Provider implementation may be simplistic and support only one specific context. Other Providers, such as the MetaFluent JMS Server Provider can support an arbitrary number of different Contexts simultaneously. To the MetaFluent JMS Server Provider implementation, a Context is just another module.

Read about examples of Application Contexts as well as the server-side implementation of contexts