Mashed Articles

JMS or Java Message Service is the basis and standard API for asynchronous, reliable messaging.

After 10 years, a new (2nd) edition of the book “Java Message Service” was recently published. Mark Richards reworked the original edition by David Chappell (ex-Sonic, now Oracle) and Richard Manson-Haefel.

Having just skimmed through the book, it did look very intersting. Obviously an extensive treatment of the API (and thus specification). But nice to see code samples based on ActiveMQ, some explanation of character encoding, use of non-JMS clients (.Net, C++), dynamic vs. administered queues, message driven beans (MDB) and Spring and Security.

Some topics that did not seem to be addressed:SOAP over JMS, REST-like access tot JMS providers, persistence mechanisms (database or file based),

Messaging solutions are still the core backbone for many ESB’s and integration solutions. The JMS API remains the standard abstration layer for both Java (ActiveMQ, SonicMQ, OpenMQ, Fiorano) and non-Java based messaging (Tibco , WebSphereMQ, SoftwareAG WebMethods, Oracle AQ) solutions.

Tags: API, blog, database, integration solution, integration solutions, jms, messaging solutions, oracle, persistence, security, SOA, soap, Software, web, websphere, XP

Messaging systems such as IBM’s WebSphereMQ and similar use proprietary messaging protocols. So some library is always needed at the client side to talk the proprietary language to the messaging server. If such library is not available for your programming language, you’re out of luck. Regarding standard API’s, JMS seems the only one ever defined.

If a messaging server exposes a simple protocol over HTTP, it becomes possible to talk to the messaging server from any programming language. ActiveMQ is a good example in that area with their STOMP protocol. IBM has the “MQ Bridge for HTTP“. And OpenMQ 4.3 now has the UMS protocol.

From quickly skimming over the REST versions of these protocols – UMS of OpenMQ in particular – they are not “pure REST” but rather “REST-RPC Hybrid” (cf. the great book “RESTful Web Services“): 1) HTTP POST is used instead of GET, PUT or DELETE, 2) the actual action is part of the URL parameters and 3) the interactions become stateful through Logon service request.

When I think about a “pure REST” approach for messaging, I expect to see URLs such as http://mq.my-org.be/…/domain/queue. Sending a message becomes a HTTP PUT action. Peeking a message is a HTTP GET action. And receiving a message should become HTTP GET followed by HTTP DELETE (receiving a message is normally “destructive” in the messaging world). How to avoid concurrency issues in this receive scenario with multiple clients receiving the same message is a REST concurrency question that I gladly pass on

Closing remarks:

• Another approach is taken by AMQP: this initiative standardizes a binary protocol between client and messaging server. Any AMQP client library in whatever programming language should be able to communicate with any AMQP compliant server. Adoption of AMQP is rather limited.
• Existing messaging products (WebSphereMQ, SonicMQ, …) can tunnel their protocol over HTTP(S), but that still requires use of their respective client libraries.
• Most JMS messaging solutions support .Net (and optionally COM).
• At Devoxx 2008, Linda Schneider will talk about “Connectivity with OpenMQ” and Bruce Snyder does university session about “ActiveMQ and ServiceMix“.

Tags: amqp, API, connectivity, iss, jms, messaging solutions, messaging system, parameters, rpc, Server, Software, system, web, Web Services, websphere, XP

All existing messaging solutions (WebSphereMQ, JMS, …) use proprietary protocols. This is not a problem within a single organization. But between organizations, standard protocols are needed. Therefore, the B2B world uses protocols such as AS2, RNIF (RosettaNet) or good old (S)FTP(S).

AMQP is an initiative to bring a standard binary wire protocol to the messaging world. Just like POP3+SMTP allows you to retrieve and send emails using whatever email server, AMQP will allow any AMQP client to receive and send messages via any AMQP compliant server.

But when I read the spec, AMQP is focusing on the client-server protocol, contrary to SMTP that is (also) used for communication between mail servers. The AMQP spec states that a bridge should be used for server-2-server communication, but doesn’t provide any details. As such, AMQP is focusing on messaging within the corporate firewall.

AMQP can be used for unbalanced B2B scenario’s, where one side runs the AMQP broker. This is a setup similar to one big company or intermediary running an (S)FTP(S) server and smaller organizations putting and retrieving files from it. But for good decoupling, server-to-server communication is preferred. The server at the sending side will take care of delivering the message to the server at the opposite side. Like e.g. AS2 does: once an organization has an AS2 server in place, it becomes equal to all its AS2 counterparts.

With all this in mind, I was a bit puzzled by Paul Fremantle’s enthusiasm about AMQP. In particular because he is the WS-RM spec lead.

WS-ReliableMessaging should have brought reliable async messaging to the WS-world. But it didn’t. The WS-RM spec doesn’t mention message persistence and so (most) vendors have an in-memory implementation, which is not reliable.

I still remember going through the book “Programming Indigo” and learning about the ReliableSessionEnabled binding property. What a disappointment to learn that for real reliability, one had to use the MsmqIntegration Binding and thus the proprietary MSMQ transport layer.

Tags: amqp, application, B2B, b2b world, blog, book programming, client server protocol, corporate firewall, email, implementation, jms, Learning, mail servers, memory, messaging solutions, microsoft, persistence, sap, Server, server communication, servers, smt, smtp, system, web, websphere, wire protocol