Yes. The wire level protocols are defined by the middlewares and message formats that OpenMAMA supports. If you are using the the underlying libraries, e.g. Avis, then OpenMAMA will be backwards compatible.
mama_open() by default attempts to load properties from
mama_openWithProperties(path, filename)initializes OpenMAMA reading the properties from path/filename rather than $WOMBAT_PATH/mama.properties.
mama_getProperty(const char* name) returns the property value given the property name.
mama_setProperty(…) alows applications to set/modify properties prgramatically.
mama_setPropertiesFromFile(path, filename) loads additional properties from the specfied file.
common/c_cpp/src/c/property.h defines the low level interface for manipulating property files. It uses the flex grammar defined in
common/.../c/properties.l to parse properties files.
Bridges should use mama_getProperty() to access properties. Bridges should prefix all properties with
"mama.<bridge_name>". The canonical form is
"mama.<bridge_name>.<category>.[<name>].property". The optional name allows for multiple
"named" configurations. For example,
mama.some_middleware.transport.my_transport.broker_address=127.0.0.1 defines the broker address for a transported named
"my_transport" on some_middleware.
The properties parser only knows how to parse the file into name value pairs so bridges need to interpret the resulting value strings. There are a few helper functions like strtobool() in
common/.../c/wombat/strutils.h; however it might be nice to start building a well defined library of property parsers/validators standard types (IP addresses, integers, comma delimited lists, etc.).
I suggest that you create
properties.h file for your bridge with macros for all your properties and a
properties.c file with functions to read and interpret them.
Currently the Avis message and Qpid proton message payloads are the only open source payload implementations. Since payloads are not dependent on middlewares, it should be possible to use these payloads with other middleware bridges.
There are of course other potential FOSS payload implementations, with one interesting possibility being Google Protocol Buffers.
MAMA currently contains default implementations for queues and timers, contained within the of OpenMAMA common libraries. We have also considered adding a default implementation for IO Events, as well as certain other core functionality, which is likely to be based on that implemented within the Qpid Proton bridge. Since most applications do not use IO Events, implementing them is optional.
In most instances,
scons -c should clean up the entire build. Failing that you can use
git clean -f but be careful as this will delete files that aren’t tracked! use
git clean to check what would be deleted.
We have considered the ability to build out of tree middleware and payload bridges, and this should indeed be possible, though at present we do not provide a SConstruct/SConscript which provides the ability.
Building multiple in tree middleware bridges is as simple as passing a comma separated list to the middleware argument of a scons line. For example, the following will build the Qpid Proton and Avis middleware and payload bridges:
The short answer is no, it’s not intended be interoperable with JMS nor STOMP. Longer answer is a bit more complicated…
OpenMAMA fulfils much the same role as JMS, in that it’s an API which abstracts underlying messaging technologies. OpenMAMA comes from a slightly different angle though in that it’s built for performance, is cross language and has a history within market data. If both OpenMAMA and a JMS used the same underlying payloads and transport, e.g. an AMQP implementation, then it’s possible that they could interoperate. It would need to be tested though as not all bindings for AMQP (for example) will use it in exactly the same way.
Credit: Les Spiro (firstname.lastname@example.org):
OpenMama can be used for more than this, but (in my opinion) the typical use case is publishing market data, for example prices for financial instruments (e.g Vodafone or IBM) from stock exchanges like (London Stock Exchange or New York Stock Exchange).
- A publisher with multiple subscribers (can be 100’s subscribers to one publisher, obviously it can be 1 to 1).
- Named streams being published, and (usually) all subscribers will see the same data for a given stream. The price for Vodafone via a stream name like VOD.LN is a typical stream name.
- Data is published using Image/Update semantics, so an initial image with all fields (typically several hundred can be a lot more) is sent to a client subscribing to a new stream. After the initial image, update messages are sent which only contain those fields that have changed (updates are typically small in range 10-50 fields)
- Potentially fast moving data. Update rates (for a stream of anywhere from 10 to a few hundred updates per second - can be higher). A subscriber can expect to be processing many thousands of updates/second. 10k/second is quite a high load for a single subscriber, I would say 50k updates / second is a high load, although there are applications that process more.
- All update streams have a state to indicate if the data is available and up to date or not (not live might mean stream does not exist, or there is a temporary problem in the stream).
- Updates can be dropped, provided the state of the Stream is correctly updated. If a problem occurs (for example overload of updates or subscriber needs to restart) most OpenMama application just discard any pending queues, request a new image and start to process the updates. There are exceptions to this (TCA and tick recording s/w) and they often struggle to recover updates that were sent during restarts.> There are loads of exceptions to the above, Subscribers and Publishers can communicate using private channels, there are tick replay mechanisms etc, but I think this gives an accurate feel for the area that OpenMAMA was developed for.