BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Interview: Jim Webber on "Guerilla SOA"

Interview: Jim Webber on "Guerilla SOA"

Bookmarks
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).

Rate this Article

Adoption
Style

Hello stranger!

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

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • 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).

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT