There's more than one kind of SOA, and the location of services vis-a-vis the firewall isn't necessarily a useful way to distinguish among them. Political taxonomy makes sharper distinctions. Motorola's central leadership was able to mandate shared infrastructure from the get-go. For the federated states of NEHEN, shared infrastructure will unfold much more slowly in a series of incremental steps.
In light of these different models, the progress of species of SOA along parallel evolutionary tracks looks like a feature rather than a bug. What matters is that both can thrive in their respective habitats. As we learned this month, both evidently can. [InfoWorld.com]
XML guru Dave Megginson has lately been a strong voice for incrementalism, and I've referred more than a few folks to his recent blog item which which says in part:
How many developers do you know who complain about working nights and weekends manually entering connection information for thousands of publicly available web services? Given that there are, at most, a few dozen sites offering web services over the public web (and that's web services in the most general sense, including REST as well as SOAP), I'll guess that the answer is "zero".
So here's my suggestion: let's hold off on designing new specifications until there's a real problem to solve. If online services continue to grow, some day my hypothetical overworked developers will emerge. When we find them, we can go and ask them what they need to make their lives easier, and then write a specification that does the simplest thing that can possibly work to solve their problem, and no more. [Problem-first design]
If you follow that link, though, you may feel that you've stumbled into an echo chamber, and in a way you will have, because Dave's item points right back at me. Here's the dilemma. Service-oriented systems that are built in grassroots, minimalistic, and peer-to-peer ways are mostly open to discussion and analysis. Those built with heavier SOA artillery mostly aren't.
In an email message today, the founder of a SOA infrastructure company ticked off the problems his software tackles: scale-out; mediation; governance; lifecycle, metadata and operations management. I know that these aren't hypothetical problems. But I can't point you to public and well-documented cases where a services "fabric" is solving them.
We heard a resounding plea from the attendees at our SOA forum: "Show us the case studies." I've made the same plea in private, and I'll echo it here. We need to open up some real-life implementations of shared-infrastructure SOA to analysis and discussion. If you've got one you're willing to talk about, please let me know. I have an arsenal of communication tools at my disposal -- text, audio, screencasting -- and am keenly interested in telling the story.
Former URL: http://weblog.infoworld.com/udell/2005/05/27.html#a1239