In this post I will try to summarize a case-study for implementing Cross-Domain Ajax support for ActiveMQ.
This makes impossible to use those messages in “trusted” applications and make them all use the same underlying mechanism. For example, you might want to create an embeddable Ajax message browser that could be used in various related applications to allow “operators” (non-technical people) to work with messages in certain queues and topics.
There are many techniques that are used today to solve this problem. Every one of them has its strengths and weaknesses. So here I will try to summarize all of them and find the best fit for messaging purposes and current ActiveMQ implementation.
This technique assumes that you put a server-side script on your client application. The purpose of this script is to get your local
XmlHttpRequest calls and forward it to the “original” provider of the Ajax service.
While this solution is perfectly valid, it is a little bit clumsy as a “general-purpose” solution, because we must provide proxies for many languages (Java, Ruby, PHP, …) and developers must find a way to “install and configure” this proxy in their application.
2. JSON and dynamic Script tag
With this technique you create a script tag that calls a remote JS script and define a callback function that script should call when it finishes. The remote script returns a result in JSON format and calls a function. In this way we have achieved a kind of web service functionality without using XML and XMLHttpRequest.
The only problem with this solution is that it is impossible to do POST method calls with it, so it is hard to send messages with it.
We can implement this solution for those who are only interested in consuming messages from arbitrary Ajax client.
Thanks to the Julien Couvreur’s excellent work (http://blog.monstuff.com/FlashXMLHttpRequest), there is another solution that is the most complete and would suit given requirement the best.
It supports both GET and POST methods, does not require any server-side proxy and could be designed to be compatible with current ActiveMQ Ajax API.
The user would use the same approach as now
We would detect whether it is a cross-domain or a local call case. If it is a local call everything would be the same as now. In case of cross-domain usage we would include all necessary files and instantiate remote version of the
From now on, I will mostly focus on the third solution (FlashXMLHttpRequest) and talk about design issues.
Besides detection of remote access and inclusion of appropriate libraries, there are several more things that should be changed on the server-side of the ActiveMQ Ajax implementation.
First of all,
FlashXMLHttpRequest does not support setting of arbitrary request headers. The only supported header in this moment is
content-type. The current ActiveMQ Ajax implementation use request parameters to pass parameters between Ajax client and server.
I thought a bit how we can deal with this issue and came with the solution that not only solves this issue, but also could make the whole implementation much more flexible and extensible in the future.
It is practically a combination of methods two and three: JSON and Flash used together.
MessageListenerServlet would make this special handling of requests that has
For example, we can now easily add support for
client acknowledgment mode, to name two.
FlashXMLHttpRequest technique, the security is handled by the
crossdomain.xml file. I’m aware that this solution also has some security problems (http://shiflett.org/archive/263), but since we are controlling the server-side of the solution we can implement various additional security mechanisms on top of that.
Also, I see this solution as primarily used in private (not public) domain and applications that knows who should do they trust. So all this should be taken cared of in the final implementation. Of course, everything is open to discussion.
This post is intended to be a conversation starter. Any comments and ideas are welcome.