Open services

Tim O'Reilly has made the observation that publishing resources to the Web, as for example in the case of Google and Amazon web services, is a bit like the open source software model, but applied to data instead. From this stems the question, "What kinds of terms of service do you think would create open-source-like freedoms in the web services world?" His article, published yesterday, is titled Do We Need A Bill of Rights for Web Services?.

I was immediately moved to post a comment, in which I concluded, "When it comes down to it, this is all about getting a service mentality; which means getting used to the idea that it's bad business practice to offer a service without publishing details of service commitments and caveats." In leaping ahead to ask about the open source model for services, Tim is actually refocussing attention on a question that Amazon and Google sidestepped by offering their services for free. Everyone needs to do a lot more thinking about what kinds of terms of service ought to be default best practice in the web services world, whether for open-source, commercial or paid-for services. At the moment, technologists are rushing ahead into piloting services without giving any thought at all to the commercial aspects of those services. Their reluctance to think about such matters is probably because, as I mentioned yesterday, the technology to monitor and analyse those aspects doesn't yet exist.
posted by Phil Wainewright 12:58 AM (GMT) | comments | link

So how do we make money?

An astute questioner at Tech Ed yesterday pointed out that the new emperor on the block, SOA, has no means of funding his wardrobe, reports InfoWorld's Paul Krill:

"One audience member questioned how services billing would be done in an SOA. 'Thirty years ago on the mainframe, on that horrible place called the mainframe, I knew every line I wrote, how long it would run, and exactly how to bill it to customers,' the TechEd attendee said.

"He questioned how, in three years, he could cobble together SLAs (service-level agreements) with an agreement that, for example, could require 20 web services calls for one unit of work — some calls within the company and some outside of it. 'For the ones outside, how are they going to bill me, where's the infrastructure to measure in commerce, all message traffic, this service delivery, and how am I going to be able to measure all that?' the attendee asked."

I raised this matter precisely one year ago: So tell me again, how do we make money from this?, and followed up with an ASPnews column expanding on the topic: Web Services Missing a Key Ingredient:

" ... virtually no meaningful work has been done to develop the technology to accurately measure usage, raise bills, collect payments and distribute settlements for multi-tiered component service delivery ... It's a telling irony that, despite all the funds that have been sunk into building the infrastructure of the Internet, so little has been expended on creating a technology infrastructure for collecting its revenues. Without the means to bill for service consumption and make a fair distribution of the proceeds to participants, the next generation of web service providers could rapidly become as bankrupt as the last."

A year on, how much progress has been made on this still vital issue? Zilch. Answering yesterday's question, a BizTalk product manager even confessed "this issue will not be resolved in three years," reports InfoWorld. He went on to imply that the question was not really relevant any more: "'The mainframe was an antiquated environment defined when computing was very expensive' and everything done had to be accounted for." This, then, is Microsoft's official line apparently — that paying for stuff is an "antiquated" notion that is no longer relevant in the web services era, and while billing and metering is something they'll get to eventually, it's hardly a priority.

Microsoft, of course, has a vested interest in delaying the day when its customers can pay for only what they consume of its products, and thus has a substantial track record of dragging its feet on the development of technologies for pay-as-you-go software services. Just ask ASPs. But SOA can't fulfil its promise until this vital component of the architecture is sorted. As Scott Swartz, CEO of Metratech, one of the few companies to specialize in web services billing, so memorably said last June, "Without billing, it's just a hobby."
posted by Phil Wainewright 1:16 AM (GMT) | comments | link

Out of synch

Several readers have responded to my posting last week on web services messaging, and the article that prompted it. None deal with my points satisfactorily, I feel.

• Doug Kaye opines that none of my suggested options will work out in the long term, concluding that "I think we'll see reliable messaging evolve during 2004." But what if you can't afford to wait that long? This was exactly the point made by Steel24-7's Anders Tholen in last week's article: "There were no alternatives. Web services ... specs are not ready yet and they are not interoperability tested."
  
  
• Ed Draper made the comment that "you have a much better solution available than any of those three in the ws-reliable web services spec," referring to the WS-ReliableMessaging spec posted at MSDN. But I took a look at the spec and, inter alia, noticed the following sentences:
  
  
  1. "The WS-ReliableMessaging Specification may change before final release and you are cautioned against relying on the content of this specification.
  
  
  2. "The protocol defined in this specification depends upon other web services specifications ... [which] ... are out of scope for this document.
  
  
  3. "BEA, IBM, Microsoft, and TIBCO Software make no warrantees or representations regarding the specification in any manner whatsoever."
  
  
  
  This is not really a solution, then, is it? It's a proposed, potential, partial framework that you might use as the basis for starting out on a solution, but it hasn't been finalized yet, and is not, as far as I'm aware, available in any shipping product. 2004 anyone?
  


• Finally, John McDowall penned a thoughtful weblog posting having read both my own posting and Doug's. He makes some important points, among which I'd like to highlight the following:
  
  

  "... to presume a homogeneous environment is a false assumption except in the rarest of cases. Traditional techniques have attempted to force homogeneity by deploying the same software at every node. This solution works when one partner has power over the others and/or deep pockets. This then puts the responsibility for change management and the definition of all interactions onto the partner with the 'power'. If the business world is considered to be more of a mesh or grid of relationships than a set of independent hub and spokes it becomes obvious that forcing homogeneity does not scale."
  

  
  This is well said, but John then goes on to dismiss ebMS in a way that suggests to me he is making some assumptions about it without taking a good look at the detail of the spec. One of its key design principles is to support precisely the kind of differential technology adoption that John cites as a requirement in a truly loosely coupled system. And while John is right to insist on a loosely coupled solution, I'm not sure that I go along with his equation of loosely coupled with minimalist.

Perhaps the real problem here is the one that Doug alludes to: "the web-services guys just don't want to embrace anything that comes from EDI." It really does seem to be the case that ebXML is from Mars, while web services is from Venus.

Unfortunately, the touch-feely good intentions of the web services guys may not be enough here. If businesses want to do serious things with web services, they're going to want proven solutions that work, not half-baked specifcations that aren't even shipping yet. However unpalatable the likes of JMS and ebMS may be to those who dream of better things, they have the advantage of being stable, proven platforms that can be deployed now. If web services people believe enterprises should be deploying something else, then it's high time they got down to business and started shipping a practical solution instead of promising yet more pie-in-the-sky.
posted by Phil Wainewright 3:03 PM (GMT) | comments | link

New logo

Loosely Coupled has a new logo today, along with some minor tweaks to site navigation. This is a transitional change, which preludes a more significant upgrade to the site's look and feel near the end of this month. It made sense to go ahead now in advance of the wider changes, so that other sites who are linking to us can start using the new logo right away. If you're already linking to any items on our site (or would like to), please feel free to highlight the link with the logo, which you can download from the site's about page.

As I write this, the changes are still rippling through the site but should be completed in the next hour or so. The final piece de resistance for today will be a new, more stylish home page design. I apologise for once again shuffling one or two items on the navigation bars. The result should be a clearer overview of the site's main features, and will make for less of a jolt when we roll out the rest of our redesign in a month's time.
posted by Phil Wainewright 6:54 AM (GMT) | comments | link