[Openmama-dev] Writing an AMQP bridge

Michael Schonberg mschonberg at nyx.com
Wed Nov 2 19:11:40 UTC 2011


2011/11/2 Raphael Cohn <raphael.cohn at stormmq.com>:
> OpenMAMA looks like it's got the potential to solve a substantial hole in
> messaging. In particular, it makes a superb way to write portable C
> applications that use MQ.
>
> We've been looking at the documentation and source, and are interested in
> working with the OpenMAMA community to develop an AMQP 1-0 bridge. We
> currently have an active open source project for a C client for AMQP 1-0,
> libamqp (https://github.com/libamqp)

An AMQP bridge would be great. I was hoping that someone would develop one
sooner rather than later.

We considered AMQP when we we looking for an open source middleware; however,
we  already had an Elvin/Avis bridge and we were short on time. We have found
that it is usually not too difficult to implement bridges around
exiting C messaging
APIs.

Please let me know through the mailing list if you require any
assistance. I will be more
than happy to assist you in any way possible.

>
> It looks like it would be quite possible to integrate this into OpenMAMA.
> The challenge is that we'd also need to define a small 'profile' for AMQP
> 1-0 vendors to support the full fidelity of OpenMAMA (eg data dictionaries)
> - we've done some work on how this might be possible. Ideally this would
> need the buy in from the other AMQP vendors. However, OpenMAMA steering
> group members and AMQP membership is somewhat aligned, so I'm sure that this
> is possible.
>

OpenMAMA provides data dictionary support on top of the payload bridge
as part of
the API. Usually it does not require any additional effort. What else
needs to be defined
as part of this profile?

I also interested in any potential enhancements to OpenMAMA that a
complete AMQP
bridge might require.

> We'd also be interested in helping write a Java wrapper, to provide a
> sensible, cross-platform alternative to JMS. As a first pass, this could use
> BridJ to deliver most functionality (http://code.google.com/p/bridj/). In
> our experience it can achieve about 90% of JNI's performance, and, with
> modification to use Sun specifics (eg Unsafe), can be used in a most
> un-Java, but efficient, manner. For the final 10% one is almost better off
> compiling a special JVM.
>

We already have a full JNI wrapper for OpenMAMA, and we should be
releasing it in
the near future: http://www.openmama.org/what-is-openmama/openmama-roadmaps.
It wraps the C API so it supports all middleware and payload bridges.

> Introductions over,
>
> Raph
>
> Raphael Cohn
> Chief Architect
> raphael.cohn at StormMQ.com
> StormMQ Limited
>
> UK Office:
> Gateshead int'l Business Centre, Mulgrave Terrace, Gateshead, NE8 1AN,
> United Kingdom
> Telephone: +44 845 3712 567
>
> Registered office:
> 16 Anchor Street, Chelmsford, Essex, CM2 0JY, United Kingdom
> StormMQ Limited is Registered in England and Wales under Company Number
> 07175657
> StormMQ.com
>
> _______________________________________________
> Openmama-dev mailing list
> Openmama-dev at lists.openmama.org
> http://lists.openmama.org/listinfo/openmama-dev
>
>

I look forward to working with you on this.

Regards,
Michael Schonberg
OpenMAMA Maintainer
mschonberg at nyx.com



More information about the Openmama-dev mailing list