Welcome!

Websphere Authors: RealWire News Distribution, PR.com Newswire

Related Topics: AJAX & REA, Websphere

AJAX & REA: Article

AJAX Requests – Data or Markup?

I just got back from the Real-World AJAX seminar in NYC on Monday

AJAX Requests – Data or Markup?

I just got back from the Real World AJAX seminar in NYC on Monday.  Pretty good event with lots of good stories. 

One issue that caught my attention was the issue of how the back-end returned the data to AJAX applications.  Most of the speakers preferred data, except for David Hansson from Ruby on Rails seemed to favor markup as the return type (at least that is what I understood him to say). 

This debate is pretty interesting.  From an Enterprise Java standpoint, the decision I believe has implications to the usage of the JSF, Struts, and Portals (in a JSR 168 sense).  Look at the picture below:




As I look at this, and think about non-functional concerns (clustering, security, etc...), the middleware can become quite complex.  JSF and Struts applications usually put a beating on Http Session, Portals even more so.  We now have duplication in MVC, both on the server and the browser.

I believe, from an enterprise standpoint, Ajax applications are better suited for exchanging data with the middle tier.  This makes the middle tier much more stateless, and therefore much more scalable.




The browser does become a bit more complex.  (Although, in the prior picture, the browser would still have a considerable and almost equal amount of work to do).  the additional work is managaing some state (the same as a well designed Http Session App with small foot print) and translating the data from some XML format to JavaScript.  In many cases this work has to be done somewhere in what is considered a web tier, because the business layer will not serve up mark-up.

If the UI workflow becomes more complex, then one should look to BPEL type engines with Human tasks and not complicate the issue with too much custom middleware.

Of course the initial hit to the server would have to go through some type of MVC middleware.  So the Struts, JSF, and Portals of the world will still have to serve up the inital pages, but from then on.

Eventually, I wonder if the initial hit could even be rendered by the browser with the server serving up some full XML document that the broswer knows how to translate to a full page.  There is much CPU out there in client land that we can take advantage of.  Although, the danger of the second coming of Fat clients has to be dealt with, we have to make sure there is no business logic out there or else security becomes a big concern. 

The browser should.

  • Invoke services on the server.
  • Move data from structures to Widgets.
  • Collect input.
  • Store minor state (multi-page wizard updates, some session id, etc...)
  • Render Widgets.
Anything more than this, then we are in fat land.  So now that I am convinced that data is a preferred route from a strategic stand point, the next debate is the wire format of the data.  Right now, I have seen 4 different approaches I have seen (custom XML, SOAP, REST, and JSON).  I wonder how the ESB of the worlds can help make a smarter controller.  I will save this discussion for another blog.


More Stories By Roland Barcia

Roland Barcia is a consulting IT specialist for IBM Software Services for WebSphere in the New York/New Jersey Metro area. He is the author of one of the most popular article series on the developerWorks WebSphere site, www-106.ibm.com/developerworks/websphere/techjournal/0401_barcia/barcia.html, and is also a coauthor of IBM WebSphere: Deployment and Advanced Configuration. You can find more information about him at http://web.njit.edu/~rb54

Comments (2) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
Jagpreet 03/17/08 02:07:53 AM EDT

Hi,

I was searching for some way for doing session mgt (Light Weight State Management) on the Client machine..i want to thank you for your blog that demonstrated the possibility using AJAX/DOJO/JSON-RPC calls. But i am still in dilema whether one should go for session mgt on client machine or not. Some of the problems that i have figured out are as follows :

1. What if client disables JavaScript?

2. Since JavaScript is visible to the client, session management on the client machine is unsafe.

3. Session management will become browser dependent because of Ajax Engine (XMLHttpRequest) which itself is browser dependent. E.g. Internet Explorer uses an ActiveXObject, while other browsers (Firfox,Opera,Safari)uses the built-in JavaScript object called XMLHttpRequest

4. No “encodeURL ()” method to achieve session management in case client has disabled Cookies on the machine.

5. The browser or user can delete cookies before it expires. So we should not rely only on cookies for state maintenance/persistence, we need to support it with server side as well.

Would like to know more about that :) thnx again.

Joel Alexandre 03/19/06 11:13:29 PM EST

>> now that I am convinced that data
>> is a preferred route from a
>> strategic stand point, the next
>> debate is the wire format of the
>> data.

JSON has been around for a while, but until "Web 2.0" came i never used it.