|
Loosely Coupled. Phil Wainewright points out a flaw in my when-to-start methodology. Using the example of the recent announcement and rapid adoption of Google's SOAP-based search API, Phil writes, "at this rate the O'Reilly book should be out by the end of the month." (I love it!)
Perhaps some context will help, although I certainly need to improve the model and its explanations. I'm not looking at the consumer's side of such a very simple web service. For something like this, it's hardly worth even suggesting a methodology, for as Phil says, it could be implemented--start to finish--in an afternoon. But I am including within the methodology's scope the ROI and timing for Google, the producer of the service.
The service requires only XML and SOAP, not even WSDL. So it's well down on the curve, not at the upper-left as Phil suggests. The O'Reilly SOAP book is out and SOAP 1.1 is final. Security (authentication only, no encryption) is handled within the application itself, so there is no dependence on any emerging standards. There are no QoS issues, no transactional integrity problems, and no need for auditing or management. Google hasn't address version control control, for example. If they change the API, our client code will likely just break. [Update: A WSDL file is included with the developer's toolkit, and consumer apps that use it have some protection against version issues.] That's great with trivial applications, but what about commercial-grade web services for which this isn't acceptable? I suggest they're much closer to that top-left corner of the curve, and hence it may be premature for some (not all) organizations to implement at this time.
Part of the problem is that web services mean so many different things to so many people. It's not going to be a one-size-fits-all world. But there's little risk to Google of their service being deployed too soon, and I believe the model and methodology apply correctly to Google's situation.
Posted Wednesday, April 17, 2002 1:12:23 PM 
|
