Does AJAX implement the Business Logic


Blogs: Does AJAX implement the Business Logic

  1. Does AJAX implement the Business Logic (4 messages)

    In his blog, Eric Pascarello (co-author of AJAX in Action) discusses the question of where should the business logic sit. Even though his focus is on client side technologies, Eric recognizes the need to keep business logic on the server.

    In this short blog he does acknowledge the point that keeping logic on the client does help to avoid expensive network calls. In the discussion he points out that a better strategy (which smells like caching) is to use logic to determine if a call should go to the server. This avoids unnecessary calls while keeping business logic out of the front end. Finally Eric offers up this nugget.
    You never built querys or logic with JavaScript code and saved it in a hidden text field for the server side code to read. All of that is done behind the scenes out of the view of the people. That same idea should apply to your Ajax applications.
    Does Eric getting all of these questions regarding where to put the business logic mean that AJAX is suggesting that developers implementing business logic in browser and is all of this leading us back to the world of fat clients?
  2. Of course, any software engineering theory dictates that any AJAX should have no trace of business logic, but that this one must be limited to the server. Any good developer will tell you that one should put all of your logic in server-side web services, and handle only the presentation issues on the AJAX client side.

    Also of course, the ability of creating business logic in a simple development environment like Javascript will lead in practice to the existence of a large number of applications with all of its business logic in the client side part. Just have a look at the number of applications existing now that have input validations only in the client side, and have the server side open to any client side mischief.

    This is one of the problems I see in all the fuzz around AJAX. In my view, Javascript is not a good, stable, reliable environment for running professional applications. In my experience, any average development team devoted to Javascript will end up creating an unmanageable mess. It is not that it is not possible to do it in the right way: it is just that the average team won't. One just has to look to all the problems JSP has created to see this (if instead of just copying Microsoft's ASP with JSP Sun would have come up with a decent component-oriented framework for creating web views -which was perfectly feasible at the time-, web development would be a lot more easier now. Then, Java trailed MS again in this, with JSF).

    I think that currently there is much more hype in AJAX than practical stuff. Although all the frenzy is also good, since it draws the attention and it is a first step. A first step towards a good computing platform to deploy client-side applications to the web: what Java applets should have been and are not because of several different reasons. Something with the robustness of Java (or .Net), the appeal and speed of Flash, and the convenience and universal availability of Javascript.

    Some day there will be such a platform, well beyond AJAX. However, it will be also thanks to AJAX.
    jcamara at softwareag dot es
  3. AJAX: A serious solution, or a serious joke[ Go to top ]

    Rich client approach is the right idea, but AJAX may be a joke.

    Using unstable JavaScript + savage HTML + amazing XML would be an explosive solution for internet users, and a lot of headache for web developers. We really need robust environments and standard well-designed frameworks. Current HTML is not a good markup language for such an approach.

    The solution:
    To give a powerful approach, here are some ideas:

    1- We need to replace HTML/XHTML with a smarter standard XML based presentation markup language. This ML would have elements like:
        <TABLE URI="..." />
    in order to cache or refresh only the TABLE element, the same way images are currently cached and refreshed by browsers. Hence, our TABLE element would be written in a separate file, and a web page would be a puzzle of separate files, written in our new ML. This method may increase the number of HTTP requests at first time the page is loaded, but will prevent reloading the same snippets of our ML code. There may be a method to reduce first time page loading (discussed later in this message).

    2- We need client-side scripts written in pure Java (not JavaScript). These pure Java scripts might eventually use XPath to access elements (tags) of our new ML.

    Using the ideas above, we are sure to have a serious approach. Further more, integrating JSF-like web components with our rich client approach would be very easy: the client would only need to cache JSF-like components (received in the form of our ML code).

    Web developpers even wouldn't need to write twice input validation code (in Java for the server and JavaScript for the client). Rather, the client would receive and cache existing server-side pure Java validation code.

    As for reducing first time page loading, imagine an intelligent web server which can send the web page with all its related components (even images) in only one HTTP response, rather than waiting for the client to request these related components. For this we would need a new tier beyond our old HTTP protocol.

    Welcome to simplicity!
  4. Why <ANY>ML and not Java Web Start?[ Go to top ]

    Why not the fat Client? Give me one reason to choose a SIMPLE-LIMITED-not-designed-to-support-enterprise-applications protocol like http over the rich experience that a Java GUI can bring to the user. The deployment issue that started all this wrong way of developing enterprise applications with html/http is the whole business of Java Web Start, so, what other reason can exist to keep "trapped" by the Web?

    Pedro Andrés Solórzano
    SCJP - SCWCD (!)
  5. The argument I hear against Fat Clients over and over is installation. I think this is a poor reason to decide your enterprise architecture and limit how you develop applications. People download and install software everyday and most don't have trouble. Look at the wide adoption of firefox, each of those users had to download and install it from somewhere. Which is worse, having to install and update an application or developing in a very limited widget set thats not truly event driven and if you want those kind of features - having to resort to an entirely different language (Javascript) to get it.