Services orchestration for AJAX

Execute process definition on the client side

By Masayuki Otoshi, JavaWorld.com, 12/17/06

AJAX (Asynchronous JavaScript and XML) is now widely known as a technique used in client-side interactions. However, AJAX requires special coding for asynchronous requests and for server-side programming. This article proposes a new AJAX approach that executes the process definition on the client. It allows you to orchestrate services synchronously and apply the MVC (Model View Controller) pattern, so you will find coding similar to server-side programming. Before discussing the new approach, let's take a look at the problems with AJAX currently.

AJAX typically communicates with the Web server using asynchronous requests so that other tasks can be executed while waiting for a response. It enables the user to interact with the browser, rather than the standard Web application. But once you decide to use AJAX, you have to struggle with callback functions. Look at the following code that executes two functions:

Listing 1. Execute two functions

funcA();
funcB();

You may expect that funcB() executes after funcA() is complete. But on the client-side, we must check whether the code calls an asynchronous request. If it does, the functions execute in parallel. funcB() starts executing without waiting for a response from funcA(). In this case, the response of funcA() is processed in the callback function (e.g., cbA()), which means we must handle an additional function for each function. Also, the use of a callback function causes problems that break the process flow and complicates the orchestration of functions. If you want to execute another function, for example, funcC() after funcA() and funcB() are complete, you must implement logic to join the callback functions, as shown in Listing 2 and the parallel pattern illustrated in Figure 1. In the list and figure, callback functions for funcA() and funcB() are defined as cbA() and cbB(), respectively.

Listing 2. Join the two functions

var count = 2;
funcA();
funcB();

function cbA() {
   if (--count == 0) funcC();
}

function cbB() {
   if (--count == 0) funcC();
}

Figure 1. Parallel vs. sequential pattern

funcC() is now invoked sequentially; however, the function is tightly coupled with cbA() and cbB(). If funcC() needs to be replaced with funcD(), we must modify the callback functions; that is, the use of a callback function affects the reusability of funcA() and funcB().

Also, if you want to execute funcA() and funcB() synchronously, without blocking code, you must invoke funcB() in cbA(), as shown in Listing 3 and in the sequential pattern illustrated in Figure 1. cbA() and funcB() are also tightly coupled.

Listing 3. Execute two functions sequentially

funcA();

function cbA() {
   funcB();
}

In addition, as shown in these code listings, we must implement the flow control ourselves using JavaScript to make asynchronous and/or synchronous requests.

Services orchestration

Thus far, we have found the following problems with AJAX code:

• Process flow interrupted by callback functions
• Tight coupling among functions
• Flow control is intertwined in functions

One reason why we are encountering problems is that AJAX is inherently based on an asynchronous model. A synchronous model, rather than an asynchronous one, is intuitive and more natural for most developers. It would prove helpful if, somehow, our asynchronous requests could be changed to synchronous ones. Moreover, the parallel pattern should be easily acceptable when the developer requires it, and flow control should be separated from the components properly. These requirements don't seem that special because they are standard for server-side development. Our goal is to apply server-side style to our client-side asynchronous model.

Archived Discussions (Read only)

Subject

Forum migration complete By Athen

Forum migration update By Athen