I commend this podcast to anyone who wants to think seriously about what is really involved in SOA (regardless of whether you use SOAP, or REST, or RSS) and whether you really need it and can afford it. This is a down to earth, in-your-living-room discussion with a nuanced view of the options for (and pertinence of) distributed applications.

Rocky, hope you don't mind my polluting your blog by posting a couple of my personal favorites, loosely transcribed [errors in transcription are mine!]. Obviously, you can delete this if it's out of line.

There's much more to glean from this podcast than my excerpts suggest so give it a listen.

SOA AS A TWO-APPLICATION COMMITMENT:

In true SOA, the service is designed as a stand-alone application … all by itself. And the client is also a stand-alone application that happens to use that service, perhaps along with many other services. It's a difficult mental adjustment to get to that point. Even though I've been commissioned to write this [one system], I'm really writing two different applications that happen to talk to each other. That's really hard … mentally. If you don't pull that off, you run the risk of building a service that trusts the client a little too much and then someone else will come along and use your service and horrible things will happen. OR you put way too much work into the service and offer a so-called thin client in which case the client gets an abysmally bad experience … kind of like a mainframe.

WHEN IS SOA APPROPRIATE?

Most applications don't have to be n-Tier and probably shouldn't be. Modern servers can handle 300 - 400 simultaneous users. That's most of the world's applications right there. ...

Even if I'm building RIAs [Rich Internet Applications], am I going to intentionally build services that anybody out there can consume … or am I creating services for MY rich client? [a panelist interjects: because in that case I can make assumptions]. Yeah, because if I'm creating for MY rich client, I can be much more "client-server-y" which is a cheaper architecture, cheaper design problem, gets higher performance, and then … what does it matter if I choose REST or Web Services. I'll pick which ever one my tool makes easier. ...

So then we're down to this tiny minority of cases where I'm not building the only client. Or you've got some gung-ho architects who declare "we're building everything with services" which is an expensive thing to say you're going to do [panelists laugh] but there you go. These folks might actually care if you use REST or not. ...

The trick is to know when to use which one. Because one of them [C/S, whether in 2-tier or n-tier] gives you low cost, high performance but is tightly coupled and the other [SOA] is high cost but loosely coupled, good maintainability, etc.. There are all of these trade-offs. For a lot of people, what's wrong with C/S? "It works good".