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).
Watch the full interview (24 minutes).
Community comments
RE: MEST
by Jan Vegt,
Links to references
by Josh Graham,
Seems not that new
by Stefano Pogliani,
A different approach with difference strenghts and weaknesses
by Johannes Brodwall,
Guerilla SOA vs. Guerilla vs. SOA
by Michael Poulin,
RE: MEST
by Jan Vegt,
Your message is awaiting moderation. Thank you for participating in the discussion.
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,
Your message is awaiting moderation. Thank you for participating in the discussion.
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,
Your message is awaiting moderation. Thank you for participating in the discussion.
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,
Your message is awaiting moderation. Thank you for participating in the discussion.
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,
Your message is awaiting moderation. Thank you for participating in the discussion.
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).