SOA skepticism

Not everybody believes the SOA hype, as our blog talkback section demonstrates week in and week out. And, in the spirit of free inquiry, we continue to welcome any and all skepticism (and downright rejection) of the SOA movement right here in this space. One forceful argument -- "SOA Sucks!" -- was recently made by Derek Ferguson of Web Services Journal.

"Now, please don't misunderstand me," he begins. "I am not saying that there isn't a myriad of benefits to be derived from exposing systems' functionality for access by other automated systems simply by passing XML across industry-standard networking protocols such as HTTP and TCP. Web services are great! If you have to interoperate with non-Microsoft systems, they may be your only option. If you are building a system today and you suspect that some other system might want to tap into its functionality at some point in the future, then you are wise to architect in a way that will lend itself to exposure via Web services."

He then launches into his tirade. As Ferguson sees it, we shouldn't embrace the idea that "that all systems should be seen either as services that expose their functionality only via unidirectional XML messaging or as clients of such systems. Specifically, I don't think that all of our problems will be solved if we move in this direction as an industry, nor do I think that such an approach is without colossal problems of its own."

He points to problems he has seen at his with his own clients: "To begin with, the move to asynchronous system operations requires a massive change in thinking on the part of most developers. Having a separate Architect role on a team can offset a lot of this difficulty by allowing just one individual to orchestrate how a set of discrete, asynchronous services can be aggregated into various useful systems...Versioning and reliability are two problems that are more tactical, and in some ways harder to resolve. If one considers the move from COM to .NET, for example, one of the major problems that .NET was intended to solve was the so-called 'DLL Hell' versioning conflicts that were common in the days of COM. Many of these problems return with a vengeance when one begins to rely heavily upon external Web services, because a change in a Web service that is beneficial to one system may be quite detrimental to another system using that same Web service. Unlike .NET code that is run in process, there are no out-of-the-box standards and tools to help with the versioning of .NET Web services."

That said, he also points to ROI problems and the challenges associated with constantly shifting standards. He considers these "the difficult questions that SOA must answer if it is to remain relevant" in the coming years and beyond.