OK, it's the Register, but a good article nonetheless. It includes a great response from Phil Stanhope at Adesso Systems. Phil wrote:
I sat in a workshop a few weeks ago with a collection of Global 500 CIOs on SOA. Interestingly, they understood that SOA/Web Services was simply when you boil away the hoopla, just an interface API. That most web-services are simple encapsulations over other (older) systems. That there is a huge difference between offering a beta service (perhaps indefinitely) in the consumer space, versus an intranet service that allows composite applications to be created in ways not anticipated in advance. But once those apps are created they become an instant legacy.
Those of them who'd had enough of an internal ecosystem of web-services up and running were now tackling the inevitable: change management and version control problems. Yes, good problems to have, but nonetheless, old problems. You can't have the Flickr experience once you have an internal application in production that sales/customer service are depending on. In many many ways, SOA as we currently have it is simply interface-based componentry where we've solved the transport/serialize/deserialize problem.
We do deeply believe in rich clients. And web services. And SOA. But there are many misconceptions out there. If you're dumb enough to deprecate a method in a web-service ... or add another one but change the semantics ... or have a required semantic usage pattern that can't be readily conveyed in WSDL ... well, is it really any different than doing CORBA/OMG, DSOM, DCOM, COM++, or Enterprise Beans? No. Are people doing this? Yes. Is it better to get a SOAP exception that fails to be able to call a method in a service? Or is it better to never be able to compile/link in the first place?
There used to be a problem called "DLL Hell". How is changing a DLL after the original software shipped any different than revising a web-services interface and having no way to change the code that called the previous one? It isn't.
Another favorite misconception of mine is that Google et al are thin-clients. Google downloads megabytes of javascript onto devices in order to do some of their latest tricks. These products have detailed knowledge of browser programming models and have developed means to improve on the plain old, dumb HTML presentation layer. But these are the same sandbox problems that virus writers, spammers, etc have exploited for years. Google Maps, in many ways, is a "clever exploit".
[This was written before the MySpace worm knocked out the site. That was one guy's first AJAX app, it took him a week to write, studying just one hour a day - ed]
My favorite way to show that Google depends on deep knowledge of the browser that it's trying to deliver bits to is to try and load news.google.com over a GPRS connection on a PocketPC Phone. It simply fails after a long-period of time (i.e it can DNS resolve, it can start to receive some bits from the source, but then it simply never loads). Hit news.bbc.co.uk (or theregister.co.uk for that matter), and guess what you get? An actual web page delivered to you that you can read. Wow ... what a concept!
LOCKSS is interesting in many ways, but it just shows one example of a valid use case. At Adesso we focus on another one only delivering the data to your devices that you need. Now, based on rules, that may be all the data you have on your other devices. Or it may be all that you need on a PDA. Or it may be all that you need to process your field service tickets.
What I object to about the Bubble 2.0 hallucination is the presumption that we're always on, always connected.
Phil Stanhope CTO, Adesso Systems
Comments