In this article, two experienced SOA architects look at the new world of Web 2.0 technologies with a critical eye and present five best practices that can help you be more successful in adopting Ajax, REST, and other Web 2.0 technologies as part of your SOA. There are several major areas in which they have learned some very painful lessons
. They share these with you to spare you similar distress, and to help you get a jump on your SOA Web 2.0 success.
Just curious, but wouldn't the first rule be to ask whether you needed it or not? I've seen many companies go off half cocked into SOA to get no benefit and suffer all the pains. After millions spent they have little to nothing to show for these efforts.
Just a thought.
What is all this crap about SOA 'methodology'? When really they mean application architecture? A methodology is a technique you use to manaage the production of something, e.g. Waterfall, RUP, extreme programming, Scrum. It is somewhat independent of the thing being produced. You typically don't talk about "J2EE methodology" or "C++ Methodology"!
Stuff like this "In order for it to succeed, Web 2.0 will also need a firm methodological basis that will be an evolution of existing SOA and object-oriented design methods." is just meaningless gumpf !!! Will it now? Got any concrete proposals then?
These people are what all the waterfall purists became after they finished their MBAs and swallowed an 1200 page SAMS 'SOA Governance' book by mistake.
From the article:
"Step 4. Have vision, establish a roadmap, and execute projects"
Management Bullshit 101.
Oddly enough, or perhaps not, absolutely nothing in this article addresses anything specific to REST or Ajax. They do use the phrase "Web 2.0" a lot.
Man, I am so sick of these marketing droids ... !
The two view-point about the service mentioned has no relation to REST or Web2.0 or AJAX. They are trying to sell two different problem domains of a "business service" as having something to do with REST? An as the article is being on a branded host, they sprinkled brand specific key-words of SO(M)A.
The title says everything. Please stop this marketing oriented publishing. Who is the editor who chooses this news ?
Come on....every best practice of the article is in the cover of every book of project management. Why is described as a REST Ajax recomendations....
SOA, Web 2.0 success is only driven by excellent project management, excellent business analysis and excellent technical skills and technologies....AS every software project in this world.
The title says everything. Please stop this marketing oriented publishing. Who is the editor who chooses this news
You've identified the source of the problem. Joe O. slipped once and awhile and posted similar crap, but since he left the postings here have almost all been crap - marketing spiel, consultant self-promotion, product announcements. There really isn't anything of substance or worth discussing here anymore.
Its like reading an IBM marketing white paper. That's all that i can say about this article
I certainly expected better from IBM for a 'technical' article, um fail, please try again.
So we say GWT, jQuery or some other AJAX framework can transform our web UI. The business managers say "So what?". Really I think this article is about how to answer that question in the context of the impact business growth and protection of existing SOA investments. Fair enough.
The problem is it's too SOA oriented - it sees AJAX (which I assume is what they really mean by web 2.0 here) as an extension of of a SOA. I think it misses the the key issues.
1) By comparison to a trad web application (e.g. JSP/Struts)an AJAX app provides a very different (much improved) kind of user experience.
2) But to do so it needs lots of small on the fly asynchronous server calls in response to user actions in the UI.
3) The response to these calls need to be ultra fast to keep the dialog going smoothly, or it just doesn't work well. There is no "page load break" as per trad web apps during which SOA orchestrations can grind away.
4) Chances are that the existing SOA services are set up to support stacking a whole e.g. JSP with data in an Action class of some sort before it's served to client as a fresh page.
5) Therefore the chances are they will not best support an AJAX application in their current form. Some will, particularly the main transaction save point orchestrations. But most won't: they'll be too slow and they won't be fine grained enough.
6) So basically moving to AJAX implies significant redesign of SOA services, and probably a lot of new ones.
It's not hard to convince business managers to go AJAX for the UI. They will soon realize if they don't do it, either a) their competitors will and they will lose market share, or b) their competitors won't in which case they will miss out on increased market share.
Much more difficult is convincing them of the required investment in refactoring the SOA to support AJAX. Partly this is because SOA stuff is invisible, "below the waterline", but it may also be because of resistance from "SOA Governance" people who may not understand the subtleties of AJAX and therefore the necessity of such investment. They may argue for reuse of the existing services, and that's an easy argument to win with business managers if they don't understand the consequences.
Which brings me back to this article: where does it highlight this consideration?