One of the things we discovered in Jazz was that when youstart thinking of defining your product's remoteable APIs asservices, that you find yourself in a position where youwant 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 verylight.
I will tell you that infinite recursive callsin a remote-to-yourself scenario are quite exciting!
Fixing the remote-to-yourself problem is simple when youknow that other service you are calling is available somewherein your current address space. Because you can just 'call'it. There are issues; like thefact that remote calls are always copying the 'parameters', but in many programming languages, passing arguments willoccur by reference. Something to watch out for, whendesigning your services around existing programming paradigmslike function/method invocations, and objects.
Now let's make the story a little more interesting. Sayyou want to call some service, which isn't in your addressspace, but is on your local machine somewhere. Do you justgo ahead and pay the cost of issuing HTTP requests, likea real client, and let your existing server infrastructurehandle 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 stillthe HTTP overhead, and that can be significant.
I'm reminded of the old Network Vehicleproject I worked on eons ago. We had this same problem. A Smalltalk programcontrolling all the devices. And a Java program running the user interface.Same box. Needed to chat. This was 1997, and while using HTTP wouldn'thave been out of the question, it was clearly overkill. So, we developed ourown 'protocol' over tcp/ip. Java could send us messages like:
and Smalltalk would receive the message and dial the phone. Smalltalk mightsend a message to Java, in reference to a voice recognition event:
Really, it was that easy. Of course, we had a finite set of messages tosend, so coming up with a simple protocol was quite feasible.
But it makes me wonder if what sort of economies might be available byspecifically avoiding HTTP, in the cases where it's not buying you verymuch to begin with.