One of the things we discovered in Jazz was that when you start thinking of defining your product's remoteable APIs as services, that you find yourself in a position where you want your server to also be a client to these services. But you obviously don't want to be making a remote HTTP call out, from your server, back to yourself. That's not very light.
I will tell you that infinite recursive calls in a remote-to-yourself scenario are quite exciting!
Fixing the remote-to-yourself problem is simple when you know that other service you are calling is available somewhere in your current address space. Because you can just 'call' it. There are issues; like the fact that remote calls are always copying the 'parameters', but in many programming languages, passing arguments will occur by reference. Something to watch out for, when designing your services around existing programming paradigms like function/method invocations, and objects.
Now let's make the story a little more interesting. Say you want to call some service, which isn't in your address space, but is on your local machine somewhere. Do you just go ahead and pay the cost of issuing HTTP requests, like a real client, and let your existing server infrastructure handle it like a remote call? For such local calls, tcp/ip overhead (to localhost) is likely to be neglible, since often this won't hit your ethernet interface at all. tcp/ip stacks aren't that stupid. But there's still the HTTP overhead, and that can be significant.
I'm reminded of the old Network Vehicle project I worked on eons ago. We had this same problem. A Smalltalk program controlling all the devices. And a Java program running the user interface. Same box. Needed to chat. This was 1997, and while using HTTP wouldn't have been out of the question, it was clearly overkill. So, we developed our own 'protocol' over tcp/ip. Java could send us messages like:
DIAL 919-555-1212
and Smalltalk would receive the message and dial the phone. Smalltalk might send a message to Java, in reference to a voice recognition event:
DISPLAY MAP
Really, it was that easy. Of course, we had a finite set of messages to send, so coming up with a simple protocol was quite feasible.
But it makes me wonder if what sort of economies might be available by specifically avoiding HTTP, in the cases where it's not buying you very much to begin with.
Photo 'Think' with a nice CC license, by Francisca Ulloa. Found using the Flickr's Create Commons Search.
