Interview: Jim Webber on "Guerilla SOA"

by Stefan Tilkov on Aug 24, 2007 |

In this interview Jim Webber, Service-oriented Systems Practice Lead at ThoughtWorks, explains his ideas behind "Guerilla SOA" – a somewhat agile approach to SOA that relies on small steps instead of a large-middleware-centric route towards service-enabling an enterprise. Jim also advocates MEST (MESsage Transfer), an architectural style that focuses on messages the same way REST focuses on resources. In Jim's opinion, the problem with most current Web services stacks are rooted in WSDL's notion of operations, which he deems to be the wrong abstraction for SOA.

Watch the full interview (24 minutes).

Related Editorial

Extend Your Java EE Apps with a Mobile Web Interface

A Unified Mobile Architecture for the Modern Data Center

Enterprise-class API Patterns for Cloud & Mobile

451 Group Analyst Report: Review of Intel & Mashery API Management Platform

API Management - Application Security Made Easy

Related Sponsor

*Cloud API Management – the Service Gateway Approach
*451 Group Analyst Report: Review of Intel & Mashery API Management Platform

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Community comments

RE: MEST by Jan Vegt Posted

Links to references by Josh Graham Posted

Seems not that new by Stefano Pogliani Posted

A different approach with difference strenghts and weaknesses by Johannes Brodwall Posted

Guerilla SOA vs. Guerilla vs. SOA by Michael Poulin Posted

RE: MEST by Jan Vegt

Based on experiences in SOA projects for the past few years as a Business/EAI/Data architect I am very impressed with the MEST idea. In the excellent interview with Anne Thomas Manes a few weeks ago here on InfoQ almost everything she said made a lot sense (in reference to my own experience) apart from one thing: this central notion and importance of type. Personally I think the MEST approach is a convincing answer.

Thanks very much for publishing this interview,

Jan
( Jan Vegt, 42, The Netherlands )

Links to references by Josh Graham

My blog entry about this interview includes links to some of the sites and people Jim mentioned.

grahamis.com/blog/2007/08/25/soa-101/

Seems not that new by Stefano Pogliani

What you describe here resembles very much to:

1. ebXML, for the message-oriented framework with Business Messages focus
2. WSCI, as a way to describe long-running conversations

Where are the differences between what you describve here and what I pointed out?

Thanks a lot
Regards

/Stefano

A different approach with difference strenghts and weaknesses by Johannes Brodwall

RPC is highly coupled and often unrobust. On the other hand, message style requires a lot of work to do simple things. The design of a web system that uses a message-oriented style to query a data oriented services is not pretty.

The danger of RPC style is that we use it to integrate systems that should be decoupled. The danger of messaging style is if we use it to distribute things that really should be colocated. Fowler's first law of distributed computing will always be relevant. Let's stop using shining new tools as an excuse to ignore it.

Guerilla SOA vs. Guerilla vs. SOA by Michael Poulin

I agree with Jim in that heavy "SOA technical infrastructure", especially ESB, is not needed in majority of SOA implementation projects because enterprises have needed technical infrastructure already. Actually, the only infrastructural element I would require for services is a service registry/repository (including policy and Service Description repositories).

However, a lightweight SOA implementation rapidly following business changes (sorry, changes of business opinions) is not SOA. SOA is Service-Oriented Architecture in business first of all. As an Architecture and as an orientation on business service it cannot be lightweight, i.e. lighter than it has to be. All candidates to business services (forget about business processes - they are just one of possible forms of implementation of business services) must be validate in business first, and only then may be released to IT for some implementation if needed.

If a business stakeholder wants something or changes his/her opinion about how something has to work, it is not enough to qualify such requirement for a new business service. The first qualifier in this case is adherence to Business (functional)Architecture, business objectives and plans. A fast production of integration interfaces - using messaging/MEST, WS, REST, ETL, IDL, etc. - is the last step in producing services while the first step is production of business functionality (a new one or a new composition of old ones).