Mashed Articles

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“.

Recently, a new book on Web Services Security was published: SOA Security. While on holiday in beautiful Italy, I went through the book. Obviously the book starts with some introduction on SOAP, WSDL and the like. But the major part of the book explains in quite some detail how to implement secure web services using JAX-RPC and Axis.

Two parts were most interesting to me personally. First of all chapter 4 and 5 on Kerberos and the “Secure Authentication with Kerberos”: it was a joy to get a refresh on Kerberos, see some sample code using JAAS and GSS API’s and see code snippets implementing the Kerberos Token Profile. And secondly Chapter 8 “Implementing security as a service”: the different models in which web services can leverage SAML are well explained. Also the relationship with WS-Trust is made.

Sometimes I got the impression that the base material was written some time ago before being published. E.g. it is a pitty that the samples are based on JAX-RPC and Axis. Axis2 or JAX-WS would been better choices. Still, the book is OK, and don’t be misled by the sample chapters online which are quite basic. But I keep hoping that one day, a 2nd edition of “Securing Web Services with WS-Security: Demystifying WS-Security, WS-Policy, SAML, XML Signature, and XML Encryption” will appear.

Note: it is clear that the authors have been working with or for CISCO as they use the CISCO specific acronym AON instead of XML gateway or similar

Many message formats have been defined for exchanging structured data: ASN, DCE RPC, ONC RPC, IIOP, DCOM IDL, , … Many alphabets have been defined, on which new languages (message definitions or RPC contracts) were built!

Although XML had its roots in the document centric world (as a successor for SGML), XML gained an immense popularity in the world of structured data. XML was considered a good standard for self-describing messages: no mixed content but tree-structured messages with data only at the leafs of the tree. First DTD’s and next XML schema’s provided mechanisms to describe the XML messages.

Pushed by HP’s eSpeak and XML-RPC, the SOAP protocol triggered the creation of the WS-* stack. But with the rise of AJAX and other Web 2.0 technologies, new alphabets emerge and gain popularity. JSON is one of those new kids on the block.

Rich Internet clients are not limited to HTML but use all sorts of message structures on top of HTTP. With the use of Javascript in the browser, a Javascript friendly protocol eases life. That’s what JSON is all about. Apart from JSON, many other protocols such as Adobe AMF pop up (performance comparison, thanks Stephan for the link).

Now, what is the impact for the integration world. Of course, JSON and others will be used for a few A2A and B2B scenario’s (although I haven’t seen any yet). But many tools will need to extend their XML support not only to REST, but to many other protocols. Organizations will keep one main entry point for all their HTTP traffic. Next to HTML and XML, JSON and others will be added. Therefore, infrastructure will be impacted first, e.g. XML gateways will need to add JSON support change their name from XML gateway

Standard ways of using JSON are already popping up, e.g. JAX-RS (JSR-311) adopted Jettison for JSON support and includes JSON-XML converter which follows the Badgerfish approach for JSON-XML conversion.

JSON-XML deserves our attention: a widely accepted XML representation for JSON (don’t use the word “standard”) will allow re-use of transformation logic. But I have some doubts around this Badgerfish JSON-XML conversion. It takes XML as a starting point, e.g. it puts XML namespaces inside JSON which doesn’t look nice.

Note: while attending SpringOne, I was caught by surprise when encountering the first use of JSON for a configuration file (for the new Spring container if I remember well)