About
Disclaimer: the views expressed on this site are mine alone and do not necessarily reflect the views of my employer or its affiliated entities.
Dejan just posted a nice writeup comparing the performance of ActiveMQ to RabbitMQ in the case of python clients. Interesting results:
… both ActiveMQ and RabbitMQ are decent brokers that will serve their purpose well in normal conditions, but put to their extremes in terms of throughput, scalability and reliability, ActiveMQ currently outperforms RabbitMQ for messaging usage in Python.
If your familiar with GWT RPC, then you you know that it’s it’s provides a very nice client side framework for doing AJAX requests against Java Servlets. The sad part is that it uses a binary protocol. That protocol is not easily understood by other languages or frameworks.
Counter that with latest AJAX rage, RESTful services with a JSON or XML representation of the data. The nice thing about using JSON with REST services is that clients and servers can easily be built it any language. Wouldn’t it be nice if you use JSON RESTful services from GWT with the ease of GWT RPC?
That’s exactly the reason I started hacking on RestyGWT. It uses a very similar development model as GWT RPC. You create a service interface who’s implementation is code generated via Deferred Binding when your GWT module is built. The developer maps the interface methods to RESTful HTTP requests using the excelent JAX-RS annotations. Just like in GWT RPC, the interface must be ‘asynchronous’. You must use callback method arguments to get the request results. But unlike GWT RPC, the data sent and received will be JSON encoded. RestyGWT will automatically code generate JSON encoders and decoders for any classes sent or received from the rest service.
For more details see the Git Hub home page at: http://github.com/chirino/resty-gwt
As of this point, RestyGWT only implements the most basic JAX-RS annotations and provides a very simple JSON encoding scheme. Despite that, the project is already extremely useful. I would love here what folks think about it.
I’m pleased to announce the release of RMI via JMS 1.0! RMI via JMS allows you do RMI style remoting over any JMS provider. It combines the ease of RMI development with flexibility and loose coupling that JMS provides.
It also supports and even simpler interface remoting model which does not mandate the throwing of RemoteException or extending the RemoteObject interfaces. It even allows remoting classes which don’t implement any interfaces via ASM magic.
Documentation still needs a little work, but the project is now ASL 2.0 Licensed and looking for contributions! Please join the mailing lists to get involved.
Changed the blog over to WordPress from Blogger. I am impressed how polished this app is. Who would have thought a PHP app could get this good?
I just saw a tweet which demonstrates that the STOMP spec still needs more clarification. I think Brian McCallister, the founding architect of protocol, will agree that one of the tenets of the protocol was for it to be simple enough to even use by user which directly connects to a server via telnet.
And to support that use case, newlines after the frame terminator are a natural occurrence. But it might be easier to describe it as:
- A stomp frame may have zero or more newlines preceding it’s command verb.