The last mile for SOA
I have been asked about how we support SOA many times over the last few months. The emergence of SOA as an architectural paradigm has been a huge influence on the middleware software market. You can’t find a middleware or integration platform today that doesn’ t pitch how great it supports SOA. Having built a couple systems with SOA technologies I can tell you that most of that hype is misplaced. SOA is really a combination of two main features. First it is an agreement by everyone to use the same syntax for interface invocations and second its a way to organize your software system’s capabilities. The first feature is enforced by standards like WSDL, SOAP, and UDDI as well as recent additions like the SCA, SDO, and of course the collection of WS-* standards. The second feature however really can’t be enforced. To me the web service standards are important but I would say the organization of software into services is really the critical feature of a SOA.
Sam Charrington in a recent interview had a great quote that I’ll repeat here about how Appistry helps in a SOA architecture:
"SOA is great about providing agility from the perspective of software infrastructure," he said. "What SOA doesn’t help with is agility as it pertains to physical infrastructure. If you have a service that is mission-critical, you end up being encumbered by a traditional IT approach."
With a traditional IT approach, if a service really takes off, Charrington said, organizations may think they have to put it on an expensive box to meet availability and performance demands. "But this is not the agility of SOA; it takes away from the huge benefit of SOA."
This is where virtualization comes into play, he said. "By virtualizing applications across a commodity infrastructure, managed by, or as part of an application fabric, you’re able to get the full benefit that SOA offers."
So basically Appistry’s EAF become the "service container" in a SOA stack. Once you have an ESB and expose your services with a WSDL interface where do you actually run your services? You can continue to run them on legacy hardware after integrating with the ESB if you wish. But at that point is when I ask my favorite question, "What happens if it works?" Basically what happens if all your efforts come to fruition and people actually start using your services? There’s really no reason to build a SOA if that’s not what you want to happen. So what do you do when you have to scale your services beyond your legacy hardware’s capacity? That’s when you need agility at the hardware layer. An application fabric is the best way to bring the promise of SOA full circle to the hardware architecture. That’s why I came up with the phrase, "The last mile for SOA". You can get close to a full SOA without an application fabric, but you may end up pushing your integration pain into a scalabilty problem pretty fast. But with Appistry’s EAF as the service container, you don’t have to worry about that either and you get the full benefit of the dream of a true service oriented architecture, not just a way to call code over web services.
-jasen
