pmuellr is Patrick Mueller

other pmuellr thangs: home page, twitter, flickr, github

Friday, January 19, 2007

Lighter than HTTP

'Think' by Francisca Ulloa

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:


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.

Software licensing and SaaS

'DayDream Believer' by Becka Spence

I hate software licenses. Well, I kind of like the WTFPL. But most of them I don't like; they're simply too complicated. And there are too many of them. I was painfully reminded of this, like I need the reminding, by looking at the Ruby license which leads to the even scarier LEGAL file.


In contrast, the Python license is a thing of beauty.

I suppose a lot of folks don't care too much about software licenses. But as a software developer that would like to consume, reuse, and redistribute as much open/free software as I can get away with, and working at a big software development house that has a tendency to attract legal attacks, I can tell you, I care. Because my company cares. More complicated licensing scenarios mean more time spent with lawyers, and less time in my text editor.

However, while day-dreaming of our eventual future, SaaS, I happened to think that all the licensing nonsense just goes away. Because in the future, we won't be delivering software to customers, we'll be delivering the results of service requests. The output of some program. And at least for the GPL, it seems clear to me that I don't have any downstream licensing issues. As long as I never redistribute my programs.

But of course, that really goes against the spirit of certain licenses, and I'm thinking of the GPL in particular. The GPL was designed to allow tinkerers to tinker, but SaaS doesn't really lend itself to that model. Maybe that's a big downside of SaaS; the loss of freedom to tinker. But more importantly, will software licenses be extended so the concept of 'combining source/programs' applies to using a client program using a service over the network? Or is this already a concern?

Blue sky dreaming? Yeah, probably. But ya gotta dream!

BTW, we will clearly have to deal with software patents in the SaaS world.

Photo 'DayDream Believer' with a nice CC license, by Becka Spence. Found using the Flickr's Create Commons Search.