I absolutely agree with this article. SOA is antoher over-hyped "word". It all comes down to granularity. The further you are from the object, the coarser(thru facades) you need to be. Another word for SOA is Facade. You provide an ''untrusted'' system with a coarse interface to communicate with your service. Big deal! I can even right now come up with another even coarser interface that goes on top of my "SOA Interface" for a heavier process.. and the shells around my object grow further and further..

Ramesh and Ashok are both right. Ramesh reminds us that there will be a need for tightly coupled traditional code behind coarse grained services for a long time yet. After all you would not build an air traffic control system with internal SOAP messaging. Ashok correctly points out the massive benefits of re-use and integration to be achieved by the standardization effort behind SOA.

When railway gauges were first standardized ROI was improved but many good locomotives were still built with proprietary machine interfaces. Over time even locomotive parts and interfaces become standardised. Clayton Christensen, who invented the concept of the innovators dilemma, points out that industrial progress involves breaking up "black boxes" into smaller black boxes with standard interfaces, driven by performance increases and technology commmoditization. This will happen to OOP software as SOA slowly penetrates, but bandwidth and performance issues will make it a long process.

The SOA hype is caused by the old hammer and nail problem. Vendors with a new SOA hammer and no OOP screwdriver will naturally characterise all problems as nails and OOP vendors will see nothing but screws.

The current capabilities of SOA have been correctly summarized by Ramesh. While technically, SOA is simply an evolution in the way we use computing and communication cycles, they harbour the seeds of monumental change yet again, as did the internet before.

What is important about these capabilities is not that we can today begin to build distributed systems focused on SOA messaging, but the model implicit in the loosely coupled and standardized access to distributed coarse functionality.

This has 3 benefits :

1. Improved ROIs and NPVs based on reduction in the risks (and the concommitant reduction in risk-adjusted discounting of future cash flows). The flexibility afforded by interoperability implicit in XSDing interfaces and XSLTing messages extend the life of systems (a-la-mainframe-legacies, etc). Keeping alive, or extending the lives of systems, to beneficially accrue future cash flows should favorably impact business cases and investment decisions.

2. Cost of interoperability and integration is dramatically reduced as extensibility and lose coupling facilitates easier enhancements and modifications of systems functionality (some overlap with 1 above). No longer do we need a big bang deployment and implementation that "gets it right" the first time. Over time, development methodologies based on xml payloads and xsd schemas will afford iterative designs and builds.

3. As standards and protocols, both dejure and defacto, find increasing traction, and as the costs of computing and communications cycles continue to drop even as performance increases, we can expect to see this "standards space" in between proprietary and black-box solutions begin to increasingly leverage distributed services. The important point is we have begun to cut through the dense brush of binary opaqueness to build the "standards space" bridges that will help us architect composite business functions and capabilities fashioned from creative individual solutions. Whether you build business functions/capabilities using Java or .Net (or other tools in the future) will become increasingly irrelevant.

Then there are the benefits, unforeseeable today, that might accrue from the higher-level standards stacks being built on the core xml technologies platform, including those for business processes, portals, etc. These standards pathways and bridges should some day allow us to wander around those vast web spaces and interact with all those wild and wonderful services waiting to be built, and integrate them into our business processes or portals on the fly.

Welcome to the world of losely coupled services!

FWIW...my two bits and three cheers for standards-based SOAs.