> > I'd say it's lower level than JMS as the threading and > dispatching is > > handled within a JMS provider. > > What I meant was that handling messages from different > sources should be unified at a higher level than the > messaging middleware transport.
Not sure I agree as I don't believe you get this in a good way from JMS but no worries. > > I guess in my ideal provider I'd see: > > > > 1. A clean simple JMS implementation. > > What do you mean by "clean" and "simple" in this case? Do you > mean not providing any functionality beyond that described by > the Sun JMS specification. I really just mean one that works out of the box without any strange configuration options or knowledge of AMQP needed to get going. One that works in an a standalone app, J2EE container and can interop with non-JMS AMQP clients. > > I've seen several mails on the merits of a public AMPQ API > on top of > > which a JMS API is layered. One benefit of this I've not seen > > mentioned is that it localises the mapping between AMPQ and > JMS semantics in one place, e.g. > > concepts of queues, topics and messages. This could be a real > > maintenance benefit as well as making the codebase clearer. > > I think that the issue of codebase structure is separate from APIs. > Publishing APIs means supporting and documenting ways of > writing applications using our software. Making our software > maintainable is extremely important but can be done without > creating additional APIs that we encourage people to code against. My point here is localising the semantic gap between AMPQ and JMS and keeping this in one layer rather than unnecesarily complicating many codepaths in your provider. You'll mostly likely have a layer to do this anyway, you may as well specify the AMPQ layer - even if only internally to start with as, at least in my view, it helps the quality and maintainability of the end product. I've been involved in the mapping of a couple of messaging products to JMS (TIBCO RV and WebMethods Enterprise - hugely different products) and it can be a bit fiddly, hence my feeling that the semantic gap is good to bridge clearly and in a well defined place. FWIW, RV was good but WebMethods did not work at all at the time. I know you'll ask why so if you're in London soon we can have a beer and can write something up! Regards, Colin.
