A few years go, both Microsoft's manager of the .Net framework and I were house guests in the same house for a weekend. He mentioned that he considered SOAP to be a possible universal RPC mechanism for all levels: method calls inside a CLR (a JVM in Java-speak :-), between CLRs running on the same server, and across a network. At the time, this seemed a little heavy weight to me, but...
This afternoon, I was experimenting with Java to Common Lisp communications. I was using the old version 1 of my KBtextmaster product (written in Common Lisp) that converts plain input text to a highly structured data object containing useful semantic information. KBtextmaster produces an XML document with this data.
To get to the point: On the Lisp side I used Sven Van Caekenberghe's nifty XML-RPC package and exposed a single lisp function that accepts a string argument and returns an XML payload as a string. On the Java (client) side, I used about 6 lines of code and the Apache XML-RPC library to test the remote service.
I expected this to be easy (and it was :-) but I was also pleasantly surprised at how low the communications overhead is. I am planning on also supporting REST, which should have even less overhead. I thought about also supporting a SOAP interface, but I am concerned that the overhead for SOAP is too large.
I am hoping that my schedule clears up a little in December and January so that I can get version 2 of KBtextmaster "shipped" - development has been on hold for 5 months, but I am really excited about getting back to work on this project.
PS. I just did a simply timing test; averaging over 100 calls, the RPC and Lisp side semantic processing was taking about 400 milliseconds per call - most of that would be in the semantic processing.