Philip Jacob

Web Services: Outside in vs. Inside out

· Philip Jacob

When I write code, I make frequent use of third party libraries (or modules or extensions, depending on the language) to save me time and increase the speed with which I can write a given application. Most frequently, I use libraries issued under Open Source licenses like the GPL, LGPL, Apache, CPL, MPL or BSD license. This is nothing new and if you write code, you probably do the same thing.

At this point, I rarely read license terms. Why? Because I usually don’t have to. I can see “Licensed under the Mozilla Public License” and know what that means because I have already read the terms of the MPL. Having to sit down and read the license terms of all of the libraries that I use would be a major distraction from my “real” work. Instead it’s just a matter of: Look for a license that I’m familiar with. Download library. Install. Use. Repeat.

Imagine my surprise when I started trying to integrate various web services and RSS feeds into my StyleFeeder project. I’ve seen Google Maps pop up all over the place, novel uses of Amazon’s APIs, Yahoo! APIs, Flickr RSS feeds and others. My expectation based on the rate at which these services are being integrated throughout the Web was that they were licensed under fairly liberal terms. But it just ain’t so.

If you were writing an application, would you incorporate a library in your application that was licensed under terms like this?

  • Required you to read and understand several pages of legalese
  • Is free right now although you might be charged for it at some point in the future at a price that you cannot negotiate in advance
  • Can stop working at any time for any reason without notice
  • Can undergo functional changes at any time without notice
  • Can be rate-limited at any time without notice
  • Does not have any service level agreement
  • Places restrictions on the data you generate using the library, some of which are bizarrely techno-legalistic and open to interpretation

Didn’t think so.

Now, when you’re working inside a big organization, all of these funny licensing oddities generally go out the window and true web-service integration nirvana can be achieved. But out here in the real world where people with clever ideas are sometimes viewed as troublemakers, being on the wrong end of a corporate law department with a big stick can be a deterrent from using services like this.

We need to see some change in the area of Web Services licenses. I’d love to be able to look at a web service offering somewhere, evaluate it and glance at the license. Oh, the General Web Service License? Sure, I know about that and I understand the terms of use for that license. Great, I can use it in my application.

Creative Commons has a set of licenses that can easily be applied to any creative work. We have an array of licenses available for software. Why do we have a one-license-per-organization model for web services licenses? There’s probably some historical context behind this, but my guess is that a generally accepted WS license that protects the interests of publishers and developers is probably possible at this point.

And, I hasten to add, it’s more important than ever. Web services are about to be flipped outside in. This terminology warrants some explanation. The traditional Web service model can roughly be depicted like this:

In this model, applications act as consumers for Web services. I need to display the current weather on my desktop, so a desktop application consumes data provided by a web service. I need to place an order for a stock, so my application makes HTTP calls to a Web service. This is normal. It’s what we’re used to: XML over HTTP. And when we’re talking about integrating different services that using different technologies, it makes sense to use platform-neutral data formats over the most widely accepted application-level protocol for data exchange.

Let’s also note some other characteristics. Control of the end-user experience shifts to the consumer of the service (since Web Services are for machines, not humans) when it is packaged up for users. The service publisher incurs a fairly apparent cost in producing and maintaining the service, but how do they support it? Remember, most of the really interesting Web Services are being produced by for-profit companies. As Ben Hyde pointed out to me, these Web Services are usually not profit centers. Mostly, they’re used to drive business to that organization’s traditional revenue channel (sell more books, put location-specific ads on maps, etc.). But, ultimately, a lot of control is handed over to the consumer of the Web service.

If you had to think of one technology company that doesn’t like to hand over control, which one would it be?

And did you notice the architecture behind Windows Live?

Here’s my read on their direction: collect a massive array of applications that are (a) created by third parties (b) that are packaged to (c) run on top of Windows Live which is not incidentally (d) controlled by Microsoft. Sounds like a platform strategy to me. I drew a picture describing this Outside-in approach to Web Services:

Control shifts back to the owner of the container in which these little web applications are supposed to run. If you have OS X’s Dashboard or Yahoo! Widgets installed, think of it as a big centralized repository of widgets that are accessed via your browser.

Let’s make a big circle and wrap this up with the licensing discussion. Let’s assume that Microsoft’s approach for Windows Live will be somewhat comparable to Microsoft Windows: a tightly controlled environment that will embrace and extend existing protocols and standards such that you can write “standards”-based code that mysteriously only runs on Microsoft platforms. Admittedly, that’s pretty cynical. But I’ll stick with it.

And my fear is that Microsoft may not be alone in thinking along these lines. People are wondering out loud what Google and Yahoo! are doing with their mapping APIs, wondering specifically how they will make money off of the service and how much they will tighten the screws on applications that they think are either too popular too inappropriate. The easiest answer is for them to start providing the canvas on which we can paint our art. And if you own the canvas, you own the art. If that’s the direction that we all want to go in, let’s make it a concious choice. Or not.

We will serve our own interests by getting ahead of these outside-in Web Service architectures by creating some licenses that can be understood and applied in clear terms so that innovative developers can do innovative things without spending time and money getting a lawyer to decipher them. Distributedness (if that’s even a word) and loose coupling are foundational principles on the Internet and Web Services fit really well on top of these principles. We need to make sure that we have an environment in which we can continue to use them in the future under terms that are understandable and that offer a predictable set of protections for publisher and consumer alike.