Re: Writing an AMQP bridge


Michael Schonberg <mschonberg@...>
 

2011/11/2 Raphael Cohn <raphael.cohn@...>:
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@...
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@...
http://lists.openmama.org/listinfo/openmama-dev

I look forward to working with you on this.

Regards,
Michael Schonberg
OpenMAMA Maintainer
mschonberg@...

Join {Openmama-dev@lists.openmama.org to automatically receive all group messages.