Talk:AJAXWorld 2007 January Article

From MemberWiki

Jump to: navigation, search

Contents

Feedback from David Frankel (SAP)

Nov 28, 2006

I did a full edit pass through the article this evening. It's very well put together (thanks to Jon for a great job!), and thus in general required only minor editing of wording and punctuation here and there. I made no structural changes other than deleting one small bullet under the "Other Factors" section that talked about Ajax and SOA; I deleted this bullet because, given the expanded text we now have about SOA, SOA should no longer be listed as an "other factor."

I have two substantive comments that might require more than wordsmithing:

1) It seems to me to be of little value to pose the question about whether transaction integrity and recoverability are important for your application unless we provide at least a few words of guidance on what the significance is of a "yes" vs. "no" answer to the question. I'm not sure what Jon had in mind in that regard, so that is why I prefer to let him address this.

2) In the conclusion it says that Ajax is a business project supported by IT and not the other way around, and that the business bears ultimate resposibility for calculating Ajax's ROI. I find this somewhat difficult to digest. Ajax is a technology, not a business concept. If we want to engage the business side of the house we have to do so in terms of business concepts or goals that Ajax technology (with SOA) addresses, such as increased ability of users to rapidly respond to business conditions and to rapidly enact innovative business processes. If Jon agrees then I'd happy to work with him to revise this language.


Feedback from Mike Wagner (JackBe)

Nov 29, 06

The SOA parts I said I would once-over are good.

On the 2) point above.... my opinion is that the business benefits of the convergence of Ajax and SOA are what are going to drive Ajax applications deeper into the enterprises. Benefits such as: Leveraging existing IT investments, Increased operational efficiency, Faster time to market for custom business unit solutions, Less expensive solution implementation.... A lot of these can be traced back to the promises of SOA, only now they are all that much easily obtainable by using Ajax to extend these benefits of SOA that much farther into the organization by extending SOA that much closer to the end user.

Incorporation of David and Mike's feedback (Jon Ferraiolo)

Nov 29, 2006 (late)

Thanks to both of you for your review and feedback. I have completed the integration of IBM's editorial feedback with David's changes. I tried my best to accomplish this merge successfully, but it was a highly manual process, so there might have been mistakes.

Regarding David's first point on "transaction integrity and recoverability", I changed the sentence to read: "To what degree is transaction integrity and recoverability critical, and how do these factors relate to Ajax partial update techniques?" Thus, it is neither a positive- or negative-leaning question, but instead just a factor to consider. (But mostly negative leaning. Partial update is more likely to run counter to transactional logic, don't you think?)

Regarding David's second point about "Ajax is a business project supported by IT and not the other way around" and David and Mike's points about how SOA is the prime driver, I did some cleanup on the conclusion to put highlight SOA and to remove the confusing sentence about "business project supported by IT". The revised conclusion isn't wonderful, but I think it is satisfactory.

Feedback from David Frankel

Nov 30, 2006 (early afternoon PDT)

I took an edit pass through Jon's latest document. His latest document merges feedback and changes from multiple sources. In my edit of this latest document, I made a few minor punctuation, capitalization, and grammar edits, and one small substantive change. The Wiki's change highlighting feature will reveal the changes, but here is an explanation of the small substantive change I made:

In the paragraph about the security implications of assembling Mashups from third-party components, there were a couple of places where I replaced "Ajax components" with, simply, "components". I did this because Mashups can incorporate not only Ajax components, but also service components that have no UI of their own. Thus, I think it's better to make the language about components more general.

I think this is ready to go.

Personal tools