Web Services Strategies
Beyond the technology, IT strategies for implementation of Web services by Doug Kaye.
|
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
|
|
|
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
|
|
|
|
|
|
