About RDS

Books and Papers

IT Conversations






Would you like to receive a weekly digest of this weblog via email? Sign up to receive my free IT Strategy Letter.



Doug Kaye's thoughts on web services, web hosting and managed services.

Liberty Won't Amount to Much. Oh, boy. I can hear the feedback (euphemism alert!) coming in already. Luc Hatlestad of VAR Business wrote this good article for ChannelWEB, giving some screen time to those of us who are less than enamored with the concept of federated identity for consumers. My opinions are the most negative in the article, which includes comments from such notables as Daniel Blum of Burton Group, Ed Giorgio at Booz Allen Hamilton, Liberty Alliance president Michael Barrett, and Eric Norlin of PingID. I admit that my final quote is brash, but give it a few years to see if I'm right or not.

Clarification: The example I published in May is of anonymous federated identity--quite different from the Liberty Alliance concept.
Posted Tuesday, July 29, 2003 10:35:20 PM   

REST vs. Loose Coupling. With regard to REST and business-process automation, Mark Baker writes, "I'd say that is what REST does best. A URI is just an identifier. I could use one to identify some instance of a business process, and at any point, anybody with that URI could invoke GET to retrieve a document which represented the state of the process. As the process makes progress (in any direction 8-), subsequent GETs will return different results representing the current state."

This implies that the document is associated with (tightly coupled to) a fixed location as specified in the URI. But a fully self-contained document can (perhaps even should) be loosely coupled as far as location. It can be sent from one service endpoint to another and another through a reliable asynchronous messaging infrastructure. The state of the business process continues to be stored within the document, but both the document and the state information are now freed from the requirement to be stored at some globally accessible location specified by a URI. The REST requirement that the URI always provides access to the current document and state of the business process is, in fact, a tightly coupled and therefore constraining concept. (Qualification: As I wrote earlier, it works great for many applications.)

Furthermore, REST requires the design and construction of highly reliable, redundant, and scalable systems. If a document is to be retrieveable via an HTTP GET, the infrastructure must be synchronous and availability must be high. A loosely coupled architecture in which documents are moved through an asynchronous messaging system allows all the endpoints to be built using lower-cost and less redundant configurations.

You can't send email to me using an HTTP GET ro POST to my desktop PC because it may be turned off. If my PC had to be up and running all the time in order that email to me wasn't lost, my PC would cost a whole lot more money to purchase and operate.
Posted Tuesday, July 29, 2003 10:08:46 PM   

California: It's a Zoo! Scott Loftesness laments the anti-business atmosphere in California. I've been thinking about my own gripes over the past few days. My son--now 27--was asking me about California economics and politics. I said there were at least two problems. One that's recently reared its head is that a small minority can initiate the re-election of the Governor only months after s/he was legitimately elected, and without cause. Unless the state constitution is amended, I predict we'll see this occur shortly after every election from now on.

But regarding the economics of the state, I think much of the problem is due to our initiative process. (I have at least a little experience here, having written an initiative a few years ago myself.) As with the recall, anyone with a special interest can talk enough voters into signing a petition and get an initiative on the ballot. Initiatives are proposals for laws that have typically bypassed the state legislature. IWO, they were rejected by the professionals: our elected legislators.

The process goes like this. First, you write the initiative. You give it a catchy title, and include as much hype as possible to obfuscate the real issue. If you're trying to spend money (and most initiatives do) it's important to say something like, "No new taxes will be levied to pay for this!" People like that. Unfortunately, no one ever stops to ask, "Well then, how will we pay for this?"

To get the few required signatures you just hang out in shopping malls. The standard pitch is, "Hey, you don't have to agree with it or even read it. Your signature will just put it on the ballot so people can vote on it."

The California ballot is filled with these initiatives, all packaged to appeal to our passions and weaknesses. Just go down the list: This one's for education, this one's for the environment. That one over there supports firemen, and the next one is for policemen. And look: not a single increase in taxes. Looks like we can get all this for nothing! We'll just borrow the money. Hey--it's just as easy as putting it on our credit cards. What's another municipal bond? No big deal.

So now the state is burdened with a huge municipal bond debt that it can only pay from the general fund or by issuing new bonds. This, in turn, lowers the ratings of California's bonds, and things just get worse and worse. When I grew up in San Francisco, our public schools were #1. Now they're #50. We have some of the highest taxes, yet some of the lowest levels of service. Why the gap? Our debt. And it's just getting worse.
Posted Tuesday, July 29, 2003 9:31:44 PM   

Mark Baker Sets Me Straight. Two weeks ago I wondered why Mark Baker thought web services were "object specific." Now I see that I took his comments out of the context of his on-going Tech Curmudgeon role. I thought he was referring to web services as being necessarily an OO technology. In fact, Mark was referring to the REST debate.

It may not be obvious from most of my articles and postings, which deal with what Anne Thomas Manes refers to as "advanced" web services, but I'm actually a REST fan myself. REST's simplicity is a great solution for many--maybe even most--XML communications problems. REST's standardized (as Mark calls it, object-generic) interface simplifies the design of many systems, but not all of them. I continue to believe that dynamic documents, such as those which evolve during a complex business process, are best communicated through non-REST style interfaces.
Posted Tuesday, July 29, 2003 6:47:32 PM   

Standards Stupidities and Tech's Future. On CNet's news.com, Charles Cooper complains about the bickering between web-services standards groups. "Unless the sides bury the hatchet, the risk is that opposing Web standards will evolve. That would further slow down business use because of concerns over interoperability." He compares this to the food fight (thanks, Rich Miller) going on in the RSS world.

It's true that the WS specs are coming about in a manner we're not used to. This model of specs-before-implementations is new in the world of public specifications, but it's certainly common within organizations and IT departments. We're witnessing the debates in public, and they're between large companies rather than individuals. We’re seeing how the sausage is made, not just sampling the results.

Time will tell whether this is a good way to arrive at standards as opposed to the traditional method of one party submitting a specification for a functioning technology to a standards body. I don't see any evidence that it's a slower process than the old way. Indeed, if you step back from the day-to-day, blow-by-blow press coverage, you'll see how far the web-services specifications have come in a short period of time. If we only saw the resulting sausage--not the inner workings of the sausage factory--I think we'd be impressed with the speed. The real question is what will we have when the dust settles? Will the resulting specifications--developed without benefit of real-world large-scale testing--be as good and long-lived as those developed more slowly using the traditional design-implement-deploy-test-submit model? That's the real unanswered question.

As to the complaint (not made by Cooper, but certainly in expressed by others) that there are too many WS specifications, this, too, will have to be judged by the test of time. Unlike the monolithic specifications of the past, the WS standards bite of smaller chunks of the problem at one time. They're "composable" (able to be combined) in the same way as web services themselves. Is this modularity of specifications as chaotic as it appears? I think not. We're just releasing the book serially, chapter-by-chapter, instead of all at once.
Posted Tuesday, July 29, 2003 8:29:46 AM   



Current Weblogs

Web Hosting Strategies
Web Services Strategies
Noise (personal)
Blogarithms (all)
(more info)




Click below for single-day archives of Blogarithms weblogs.

July 2003
Sun Mon Tue Wed Thu Fri Sat
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31    
Jun   Aug

Click to see the XML version of this web page.


All content on this web site is governed by a Creative Commons License.
©2001-2003 Doug Kaye and RDS Strategies LLC (