I recently joined in on the thread on theserverside.net and thought I'd cross-post my views on my blog.
I think the real reason we see so much hype around SOA is because the industry has so much momentum in the opposite direction (thanks to the EJB movement and most of the enterprise technologies from Microsoft over the past 10 years) that it really needs a very hard push to change direction.
They may be ideas that have been around for a very long time, but not everybody has realized the true benefits they bring together as a package. The originality is in bringing all of these ideas to the table with a realistic plan to make it all work, and a common protocol so that everyone can use it regardless of their platform or infrastructure. SOA is a packaging and branding of these ideas.
Loose coupling, developing against schema rather than types, using open protocols, black boxing your functionality - there's obvious benefits to adopting these concepts in your designs. For example, developing against schema rather than object types means you're not required to implement the services of the object and share type with the object to interact with the service. It means the data can originate from anywhere. Using open protocols broadens the reach your services have, and loose coupling promotes re-use of your components so they can serve as a true asset of your business, rather than simply a component of a specific application. Black-boxing means more opportunity for stateless calls, and that opens up an array of opportunities for scalability through load balancing and resilience through fail-over.
But implementing these concepts doesn't come easy with the technologies that we have at hand today. Sure it's possible, but it's not straightforward. With today's technologies you have to pretty much piece together the solution yourself. Programming languages don't natively support interacting with schema, everything's pretty much static and hard-wired at compile time. DCOM and .Net remoting certainly don't make it easy to write loosely-coupled systems because of their reliance on type compatibility rather than schematic equivalence.
The more hype that surrounds SOA 'the package', as an atomic set of principles, the more the industry will come to accept this as the de-facto way of architecting applications, and the more pressure will be on Microsoft and Sun (to name but two vendors) to embrace the principles and provide better support in future frameworks. Microsoft are already heeding the call with Indigo, lets hope this is just the beginning.
I agree there are still problems that need to be completely resolved, cross-platform distributed transactions and security are just a couple. Performance is also a big factor that may never be overcome because an architecture based on loose coupling and effective anonymity can make far less assumptions about the context in which the service is invoked, requiring extra validation and data "baggage" to be carried between calls throughout the system.
But I think even with these compromises what you end up with translates to huge gains.
I think the reason there's so much resistance to SOA is because the gains are measured more in terms of your company's bottom-line than "coding elegance": It's more of a manager thing than a programmer thing, so the push has to come from the top down. And this is why we see so much "marketing hype" about SOA, because the gains probably aren't all that attractive to your average coder, so they need to be communicated in a different language.
In the hands of your average coder we end up with technologies that look elegant on the screen, but often stink in practice. It's time to hammer some of these "obvious" ideas that service orientation represents into the programmers doing the work, and that's only going to happen with support from framework vendors and managers, and we need as much hype and communication of these ideas as possible to make that a reality.