There was some talk of a C# interface.
JBossMQ network protocols employ a lot of Java serialization, which would probably be fairly strange to work with under C.
I think your best bet would be to write your own IL (possibly based on the design of UIL2) which serializes/deserializes message traffic in a more language-agnostic format. This sort of "plain" interface would perhaps be much faster than using Java serialization.
I don't think it would be a lot of dev. work on the Java side. There might be some way you could have UIL2 use either serialization strategy, keeping the codebase mostly the same. The C side, on the other hand, would probably be harder, depending on the feature set from JMS you're duplicating.
So I assume that IL == Interface Layer?
Could you point to design documents for UIL2?
I'm most interested in the publish/subscribe capabilities.
Another random idea that I've been toying with was to try and leverage something like Sun Java Message Q, which provides a C api to route messages from C to a JbossMQ. The reason for this extreme overhead is that we wanted to use the failover/persistence that seems to be provided by JBoss -- and avoid the prohibitive price associated with the enterprise edition of the Sun product.
And truth to be told, I'm trying to support a set of user/developers that are doing most of their coding in Perl and would like to keep it that way; using something like SWIG to provide support for the Perl developers. There has to be an easier way...
IL = Invocation Layer
The plan is to merge the JBossMQ ILs with the more generic Remoting Framework.
If you are in a rush, then implementing your own IL might be the fastest way to go.
However if you can spend a bit more time you can make a significantl contribution by implementing asynchronous web services around JbossMQ.