Good protocol for FAST inter-application communication?

Question

I am about to implement a server application that can answer queries fast. The server is implemented in java. I don't want to waste a lot of time on a complicated communication protocol so I search for a good best-practice way of 1) performing a query to my server 2) letting the server answer that query Both the queries and answers will be maps from integers to integer lists.

Related: Are there any combined framework that both handles the query/response protocol AND manage incoming queries (puts them in a queue)?

I don't know if I should implement it as a plain daemon or a web service. A web service seems more flexible as it can be relatively easily moved to another machine but a plain daemon sounds faster.

Answer 1

I know this is kind of a general answer, but you're talking a difference of milliseconds between a daemon and a web service.

With that said, go with the more flexible architecture. Good design will FAR outweigh the technology you use to execute it.

If a couple milliseconds really counts, then the question is not which technology to use but how you can use caching and load balancing to scale it.

Answer 2

You could follow the leader and user HTTP for that :)

For instance in their AJAX API, they use it in conjunction with JSON ( or is it plain javascript ? )

Here is an example.

For the following query:

http://ajax.googleapis.com/ajax/services/language/translate?v=1.0&q=hello%20world&langpair=en%7Cit&callback=foo&context=bar

The complete output is this:

HTTP/1.0 200 OK
Date: Thu, 12 Feb 2009 05:13:31 GMT
Content-Length: 97
Content-Type: text/javascript; charset=utf-8
Expires: Thu, 12 Feb 2009 05:13:31 GMT
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
X-Backend-Content-Length: 16
X-Embedded-Status: 200
X-Content-Type-Options: nosniff
Server: GFE/2.0

{"responseData": {"translatedText":"ciao mondo"}, "responseDetails": null, "responseStatus": 200}

Of course the test is very simple, but using java the implementation could not be simpler that that.

Of course it depends on your project needs, security, access control etc, but by using HTTP you can relay on a super tested protocol.

Answer 3

If performance is that much of an issue I suspect you well need to go for some kind of grid of cluster solution. I wrote an overview of Java grid/cluster libraries awhile back that is useful background.

If commercial software is an option I'd suggest looking at GigaSpaces (or some freeware JavaSpaces implementation if not). It'll allow you to do:

• FIFO ordering of messages, if that's important to you (although that comes with a performance cost);
• Sub-millisecond transactional grid updates;
• It comes with a JMS implementation built on top if you want to use that queueing API; and
• Messages are defined by class so you can just read/write the appropriate operations.

GigaSpaces (and any serious grid/clustering technology really) scales well. Much better than a pure queueing solution, which either doesn't scale with publish-subscribe (since all listeners receive a message; not typically what you want) or request-response (where you have to make sure the queue isn't blocked by a bad message).

You don't mention what technology the server is using. If it's Java then you're OK. If not it gets a little more interesting. If that is the case you may want to consider building something using Google Protocol Buffers, which is a high-performance binary interchange format and is supported on Java, C++ and possibly other platforms.

Personally I'm not a huge fan of Web services because they're not transactional (in the sense that they can't enrol in distributed transactions). That may or may not be an issue for you. Plus interoperability between different technology stacks (eg Java and .Net) is still problematic at best.

Answer 4

If you develop a daemon server, what interface you are providing clients to connect? You would be implementing sockets or RMI or something else. Not a very flexible and easy to maintain solution when it comes to scalability.

Go with webservice.

Answer 5

A daemon will be faster in the short term at the price of flexibility. The advantage of the daemon is that you can just send the reply back in a compact form, in your case as a stream of binary integer values. This will be as fast as you can get.

If the number of requests increases beyond a certain limit, you can use DNS with Round Robin to spread the load over several machines, so there is no advantage of using a HTTP server.

The main drawback is that you can't debug this interface easily (with most Internet protocols, you can just telnet to the port on which the server listens and run a couple of commands and see the result). Also, if you have to change the interface for any reason, you will have to change every client as well. This gets worse when you need to use this service somewhere else, for example in a mashup.

So if you want to be more flexible, use a protocol like HTTP and JSON as the data format. This is not as compact as the binary, so answer times will be worse. How much worse depends on the size of the data. If you can fit the JSON encoded response into a standard IP package (about 1500 bytes), you probably won't notice the difference.

Answer 6

unless you have tried multiple methods, you wont know which one is "better". The best way is to prototype each, and try it! it doesnt even have to do all you want to do, just do the basic bits (like returning predefined data), and you can load test it to see which one is better.

i suspect that these days, modern machines will perform fast enough for http to work reasonably well, and with the added benefit of being more standardized, other services can take advantage of your server without needing a specialized client.