The time may be ripe for 'Guerrilla SOA'

Finally, Jim Webber (aka World Wide Webber), SOA practice lead at ThoughtWorks and a colleague from WebServices.Org, is pushing his "Guerrilla SOA" concept to a wider audience, and I think he's on to something there.

As he recently discussed in this new video podcast with InfoQ's Stefan Tilkov, Guerrilla SOA is all about well-targeted, lightweight engagements to address specific business problems, versus the Big SOA approach promoted by many vendors.

The traditional approach to SOA is more "akin to mobilizing an army," he said. "You have hundreds of consultants, a whole bunch of armaments in the form of huge sophisticated middleware platforms, and, the whole thing is very heavyweight and somewhat cumbersome."

So what exactly is Jim's Guerrilla SOA approach? He says the emphasis is loose coupling, and on the message being sent, not the infrastructures that process the message. First, it's important to "decouple dependencies between what the businesspeople want and the tools we have available -- ESBs and so on," he says. While he doesn't mean to pick on ESBs, the use of tools should focus on individual situations, versus a blanket enterprise approach. What works in one situation may not be suitable for another.

Plus, Jim added, there is no room for operational details in SOA. "Operations are an abstraction which I do not believe exists in a service-oriented architecture," he says. "They will exist in your implementation of a service, but it’s nothing I want to share with you. This is a technical detail which is my business inside my implementation... I can't invoke you. I don't have that strength. For all I know, you're a third party in another enterprise. All I can do is request."

"The importantthing is I don’t let my current development context leak into other development projects," Jim says. "We like to keep each process that we're implementing relatively isolated, so that the service ecosystem grows."

Jim's approach reminds me of something BEA's Paul Patrick told me last year, that SOA is developing in a similar fashion to the Internet, that is, as "neighborhoods" of systems that spring up to serve more localized requirements. Eventually, just as was the case with the Internet, these neighborhoods will start joining into a greater federation.

I suspect Jim sees SOA progressing along a similar evolutionary path, as islands of services begin to bridge together when and where it makes sense.

The vehicle Jim says can bring this about is MEST -- for Message Exchange. (Yes, it's a play on the term REST, and has many similarities to REST.) In MEST, Jim explained, a message will contain two things: the business payload (purchase orders, invoices, etc.) and the metadata that contains the processing context for the payload. "The MEST idea is that I’m delivering you a message. You’re going set the conext of processing that message, examine that message, and process that message. End of story."

(Savas Parastatidis provides an overview of what MEST is all about here. He sums up MEST's mission this way: "We would like to see MEST become for service-orientation and Web Services what REST is for resource-orientation and the Web.")