We need 'enterprisey' SOA, and here's why

Lately, the fur has been flying around whether enterprise SOA is more suitable for service-oriented environments than more Web-2.0-ish approaches, and I've been relaying the observations of Daryl Plummer, Tim Bray, (and here)  John Nagel, Phil Windley, Jason Kolb, and Nick Carr.

Eric Roch, chief technologist for Perficient, recently blogged that he doesn't understand why there is this raging debate between enterprise SOA and REST.

Roch, who reports he is working on several enterprise-wide SOA transformation projects for very large companies, says he "cannot imagine telling one of these clients we can solve their problems simply by using a REST approach." REST may not be enough for decomposing complex business processes into well-orchestrated business services, he says.

Roch points to three areas where enterprisey SOA fills the bill much better than REST: 

• Aggregating fine-grained services into business processes:"To put URIs around a set of services that will never be presented in a browser to be aggregated for reuse doesn't make much sense. Even if Web services did not exist, I would not use REST for this purpose. I would use messaging such as JMS."
• Messaging inside the firewall: "It is often desirable to use SOAP over JMS versus HTTP inside the firewall to simplify transaction management and security. For example, you could expose a Web service as HTTP(s) externally and though a gateway service as SOAP over JMS internally. Protocol abstraction, security and transaction management are more enterprisey details you have to bake into your SOA."
• Development tools: WS-* may be complex -- with more than 60 specs now -- but "the tools being created now for developer's use are moving to WS-* standards support to solve enterprise class problems."