Hi Folks,

On 3rd September, we had a productive workshop session in London focused around Dynamic Bridge Loading, Entitlements Bridges and Acceptance Test Suites.

We had great representation from software vendors, customers, contributors and users. I would like to take this opportunity to thank everyone who attended to help make it worthwhile, and to extend this invite to anyone else who may want to attend the next session on 24^th September.

The notes from the session are listed below:

Dynamic Bridge Loading

Implementation Notes:

·         Mechanisms should be put in place during the bridge loading process to enable MAMA to reject incompatible bridges and for bridges to reject incompatible versions of MAMA. In future, this could potentially allow MAMA-to-bridge behaviour to be changed between major MAMA releases as it would mandate a recompile rather than risk a crash. Debatable at the moment as to whether to implement this in a manner consistent with the existing ‘internal properties’ mechanism or to create explicit functions specifically for version validation.

o   Option A is to use a known struct containing version information as part of the handshaking

o   Option B is to use the existing internal properties hash map to store the version information as a string and provide utility functions to parse it

·         The mechanism already in place for a middleware bridge to specify a list of supported (or certified) payloads should remain in place.

·         A configurable 'default payload' should be a configuration parameter applying primarily to the publishing API to allow it to determine which payload to use where none is specified in code, and the middleware supports multiple payloads.

·         Where multiple payload types are supported, the same transport should be able to decode any payload type received (for the use case where a publishing application knows that different payload formats may be more efficient for different message types).

·         As general approach, loading of transport and payload (and entitlements) bridges should be configuration-driven. Earlier loading of mama.properties should allow for this. Internal structures that are required containing payload/middleware identifiers should be populated on loading from configuration. Introduction of a new middleware transport/payload (or entitlements bridge) should require only a configuration change and placing the new libraries in a location where they can be found.

·         The latest implementation of this which is a hybrid of a few submitted approaches can be found in this github fork / branch

Related Notes:

·         Details of the currently favoured implementation can be found at http://review.openmama.org/D15 and may get merged into a feature branch shortly also.

·         MAMA Middleware should never refer specifically to payload types.

·         Payload should also never refer directly to external payload types where a mama message object is provided.

·         Where a middleware bridge recognizes that it has received an attempt to publish a known unsupported payload format, the message should be dropped.

·         The approach of taking the responsibility of creating the bridge implementation away from the middleware bridge developer was deemed acceptable.

Entitlements Bridge

Implementation Notes

·         The entitlements bridge should be a standalone bridge which has no dependencies on the middleware implementation which may or may not underpin it.

·         Does not necessarily need to be based on the generic plugin API.

·         The entitlements bridge has sole responsibility for managing entitlements and taking decisions on whether any attempt to subscribe or publish data is allowed. In the exceptional (not default) case it may be desirable to defer entitlements checks to a middleware transport bridge (where that middleware has built-in entitlements controls). To allow for this, it would be useful to pass some identification or reference to the middleware being used to the entitlements bridge when making entitlement checks. It is up to the entitlement bridge implementation to decide whether it wishes to defer checks or not – this cannot be overridden by the middleware transport bridge.

·         All calls to the entitlements bridge should include a handle to the middleware bridge where applicable so (for example) in future bridge implementations, it could confirm from the bridge whether it is in fact deferred or not.

·         Which entitlements implementation to use may be Global (as they are today), bridge-specific, transport specific or even source-specific, so deferring to the entitlements bridge implementation should allow it to make this decision and manage all related state.

·         Needs to be run-time as opposed to compile time configurable. This means that all of the #ifdef WITH_ENTITLEMENTS stuff gets removed, so this is not optional, replaced by function calls to the loaded entitlements bridge. An entitlements bridge MUST be loaded.

·         A bridge specification for this should be published to allow third party vendors to implement their own hooks.

·         Publish side entitlements is required.

Tick42 Acceptance Testing Notes

Implementation Notes

·         Proposal would involve a series of tests that can be run on a MAMA bridge to ensure an application developer can easily know which bridge supports which range of functionality.

·         Test suite may need to be based on canned data if possible to validate expected content rather than simply checking whether or not content was received.

·         Test suite would be open sourced.

Related Notes

·         Agreed that the list of bridge-specific features was fairly comprehensive though it may grow with time.

·         Agreed that the main use case for this would be a large table of reference published on an OpenMAMA page detailing compatibility for all known resources.

·         For bridges which map message fields to traditional 'w' fields and corresponding types, these mappings should be made public so that any applications which wish to integrate with the bridge can understand the field mappings while doing so.

Tangents and Wish Lists

·         In some bridge implementations existing at the moment, meta data such as the ability to clear a cache which would be useful for the MAMA application to receive does not currently propagate to the application. Investigation would be required to see if message types alone would be sufficient to cover related use cases. Potential suggestion for Meta data being moved outside of the MAMA Message itself if message types are insufficient and instead, meta data accessor functions are required.

·         Review process for OpenMAMA is currently opaque as it is subject to Engineering process. SR to have a discussion surrounding this with moving to Github and carrying out code reviews there being a potential option.

·         OpenMAMA Source discovery support was raised. Suggestion that taking the DATA_DICT approach of simply having a special topic which the bridge can expose to the application in a standard way may be sufficient to solve this, if the approach is standardised and documented.

·         MAMA Date time is not safe for the year 2038 problem - something which is already being hit for some expiry dates.

·         MAMA Date time also suffers from some precision and hint problems in .NET.

·         Bridge specific latency measurements would be a useful tool to analyse latency being introduced as a result of the bridge implementation rather than the middleware itself.

Cheers,

Frank