A few qualities of web services

Asymmetrical Benefits.. Glenn Fleishman--who created the book-finding site, isbn.nu -- writes that "Web services fed by companies that don't offer two-way contracts -- contracts that promise continuity, uptime, consistency, and persistence -- will make application developers nervous about relying on them."

This is a critical and non-obvious issue. First of all, sites like Glenn's, which depend on aggregating multiple web services, must be resilient. If the Amazon service doesn't respond, isbn.nu still shows data from the remaining booksellers. In this sense, isbn.nu is loosely coupled.

Amazon.com won't even notice is isb.nu goes off line, so there's a substantial asymmetry in their relationship. Glenn's point is that more business-critical applications, the less significant partner will hesitate to depend on such a relationship unless service-level commitments are offered. (Glenn was one of those people I wish I'd been able to spend more time with at the O'Reilly conference.) [Doug Kaye: Web Services Strategies]

A few comments: One I wish http://isbn.nu becomes more widely known and used. It's rather unfortunate (okay make it very unfortunate) that so few people use ISBN.  Isbn.nu is a great resource if you want to hyperlink a book, not a bookseller like Amazon. (Yes I understand people link to Amazon because of its market dominance and large inventory and by sheer force of habit.)

Now on Fleishman's comment about desirability of web services "contracts that promise continuity, uptime, consistency, and persistence".  I think we'd be better off if we think about these desired qualities in terms of business process, abstract user interface, requirements definition rather than in terms of current web services technology.  (The latter is about mechanics or at best low level procedures.)

For a starter, how do we agree on "continuity"?  Is it analogous to "Cool URIs don't Change"?   Is continuity same as idempotent?  Or how about referential transparency?  What kind of services and resources can have continuity as quality?  Looking up a book has simple continuity (ISBN is permanant) but what about finding weather information? 

How can we square continuity with persistence?  One handy notion of persistence is the ability to retrieve past records - but this notion leaves a good deal unsaid about possible ephemeral side effects from CRUD operations on those records.   (Reconstucting trails of these side effects can be fun fun fun.)  Another notion for persistence is about data retention, removal, segregation, etc.  Thinking about data retention alone would make you seek expert legal counsel - think subpoena - and insurance brokers.

My take on consistency is another simplistic notion of "quality of service" as understood by laymen like "I've been drinking Peet's coffee for 20 years because of their excellent taste."  As Wily E Coyote would say, "I trust Acme Company's products with my life."   I wonder if you can legimitely complain about consistency of service when you hit jackpot using the lottery numbers from a web service?

As Doug Kaye says all this is "non-obvious" (which I'll translate for myself as "bloddy difficult").

[A side note to myself:  equating URIs to addressibility doesn't help.  A sheet of paper is exchangeable with another.  Think Bose statistics.]

[Another note: qualities are in general not orthogonal to each other.  If they were life would be so easy yet so boring.   But then orthogonality is something many smart people believe in, worship and love.]

[Yet another random tangent: "Contract" has been a buzzword for IT industry for a while (How much is it due to Design by Contract?)  but has anyone developed real enforcement mechanisms?  In real life contracts are drawn and broken willingly and unwilllingly all the time.  Unlike binary software arbitration, determining how a contract is "honored" or "broken" is a fairly complicated and nuanced process.]