it was a good read
in any case, I can't say that I've ever thought it out as completely or spoken it as articulately, but I've had that kind of gut feeling about the demand for open standards eventually driving proprietary vendors towards open-source.
but, lo, what is this? one of our very own open source champions is pitching a marketing gimmick, and it is received positively by the open source community? and by community, I mean, y'know...you.
I thought the community/you had a pretty anti-marketing mindset...? could it be that marketing, as an act of conveying information in a targeted manner for maximum persuasive impact, is actually beneficial, even praiseworthy?
Sabre is as cool as Google
and they are located in Southlake, which means you should get a job there tomorrow.
"marketecture"
Adam Bosworth from Google was probably the first to destabilize my vision of a global information marketplace using only SOAP messages. he talked about REST at the Web 2.0 conference in a discussion panel titled "The Platform Revolution," and what he said really stuck with me. I don't have any quotes or minutes to look up, so listen to the entire discussion (~1 hr.).
essentially, Bosworth asserted that it is human imperfections that encourage innovation and creativity. and he quickly summarized what I'm about to say in more length...
how this relates to REST vs. SOAP is that SOAP is designed to be The Solution - created to faciliate all communication needs for every situation and in such a way as to be completely and totally independed of underlying transport, extensible beyond imagination, etc. however, that also means that SOAP is very complicated. in order to understand the 'why' of SOAP, you have to at least dabble into a large number of example scenarios of usage of each of the features of SOAP before you appreciate the inclusion of all the complexity. there are (and will be) some good books about it, and I've been thru some. I think I now understand most of the "why" of the complexity of SOAP.
but as I've been learning, knowing the "why" of something is hardly sufficient, even less so when that something is to be used for solving real-world problems. one problem might be the need for cross-communication between system X and system Y by date D. in the purely theoretical world, absent of the date D parameter, you choose SOAP and work until you've got that loosely coupled, platform-independent, extensible solution. but since date D is important in the real world, the below example shows that perfect elegance is not always the best option, and is sometimes no option at all.
I've also done work with REST web services. and I must say that the simplicity and ease of REST is no small convenience. specifically, we consume our current UPS web serices via REST, and we will likely be expanding the number of services we implement because it was only a matter of a few hours from start to finish on implementation. by contrast, when we explored replacing our in-house, expensively maintained, sales-tax tracking system with a StrikeIron web service, we initially had only the WSDL, and therefore SOAP, to work with.
to the discredit of both ColdFusion MX and PHP 5, we found that neither includes built-in, functional support for inclusion of SOAP Headers. In the case of PHP 5, it mangled the XML markup in the header by invoking an http_encode type transformation on it, and it also prematurely closed the root element of the SOAP Body, in addition to erroneously skipping over the first of the items in the parameter array. ColdFusion MX has no support for SOAP Headers, until you download and install an update. And even then, we never were able to work with it, because it would just outright fail to parse the WSDL correctly.
however, to the credit of REST, we were able to more simply and easily work with an RPC-type interface by issuing simple HTTP GET (included in both languages) with the two arguments and receive our XML response. bliss.
it can be reasonably assumed that these particular faults will be corrected in future versions of the languages. indeed, it's easy to think back to the days when HTTP was the brand new, complicated transport that had numerous problems and bugs as people were still learning how to use it. but it doesn't change the fact of the matter that as of right now, before date D, REST lets us do what we need.
bringing it back to the idea of human imperfections...
most reasonable system analysts will say that the REST systems we have implemented are imperfect, and they're correct. but, because it is working right now, it enables methods of communication (however "clunky") that foster innovation in other places. ie, the business users of our system who now have more tools available to them.
now, I'm hardly an advocate of inelegance, and I'd love to eventually replace our REST interfaces with SOAP and WSDL interfaces, along with lots of other changes to our current systems. but as an interim measure, or a quick-and-easy solution, take a REST.</div>
good model
WS-Kernel
I have wondered if something like this were going on, but my initial assumption was that XML processing load made it impractical for low-level system operations. at kernel level, things need to happen fast, and the vast majority of the time (especially in Linux), it's possible, or even easy, to write system components that speak directly to the kernel.
I think the initiative is great, though - the more software projects out there, the better. the area I see service-oriented architecture providing the biggest benefit is to business processes that span multiple disparate systems. I have never thought of an OS as fitting that description at all. however, there may be some killer ideas out there that were waiting on this technology.</div>
