Watch the full interview (24 minutes).
InfoQ Homepage News Interview: Jim Webber on "Guerilla SOA"
Interview: Jim Webber on "Guerilla SOA"
Watch the full interview (24 minutes).
Facilitating the Spread of Knowledge and Innovation in Professional Software Development
Write for InfoQDiscover new ideas and insights from senior practitioners driving change in software. Attend in-person.
Discover transformative insights to level up your software development decisions. Register now with early bird tickets.
Get practical advice from senior developers to navigate your current dev challenges. Register now with early bird tickets.
Level up your software skills by uncovering the emerging trends you should focus on. Register now.
InfoQ Homepage News Interview: Jim Webber on "Guerilla SOA"
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).