Ronan Bradly started it by specifically picking on Iona, Joe McKendrick refereed, and now David Linthicum is providing his analysis and opinion.

It's been an interesting few days in the blogosphere where SOA is concerned. Analysts have been quoted. Standards have been compared to train wrecks. Products have been picked on, and bloggers have climbed up on their SOAP boxes.

Pun intended.

We all have our very own SOAP boxes where SOA is concerned (or at least those of us who've been intimately involved in SOA since it started picking up steam have one - mine is pretty scuffed up at this point), mostly because the definition of what a SOA is or is not - and the best way to implement/deploy one - is as loosely coupled with a solid, acceptable definition as the concept itself. If you put five "experts" in a room, you'll get five different answers as to what constitutes a SOA and what the best way to build it may be.

In the end, though, it's all about flexibility. SOA is by definition flexible, and it's really whatever you decide it is. There's no single product that makes up a SOA; you can't buy it in a box no matter what some vendors might try to tell you, and no one can tell you with any real authority that you're doing it wrong because the only real metric is whether your SOA fulfills the needs of your business.

If your SOA initiative - whether it uses code-generation or not as a service-enablement mechanism - is meeting the needs of your business then you're doing it right. SOA doesn't have an RFC that an expert can point to and claim someone else's implementation isn't compliant, it doesn't even have a set of agreed upon best practices upon which you can rely. Having either would destroy one of the greatest benefits of SOA - flexibility.

Now I know you're wondering why someone from an ostensibly network-focused organization is penning an opinion on this particular argument. The flexibility of a SOA isn't just for applications, it's a concept that should be applied throughout the entire infrastructure stack - including the network. Without the ability to adapt to your unique SOA environment the network is nothing more than a collection of wires that has the potential to impede the delivery of your SOA instead of improving it. Really. Our own Jeff Browning does a great job in this article of explaining SON (Service Oriented Networking) and on the importance of SON to a successful SOA.

We think the network should understand applications, and that's why we're interested in SOA and hence interest in this particular blog war. We've always been focused on improving and securing the delivery of your applications and SOA is no exception.

Imbibing: Coffee and Mountain Dew