TIBCO’s AJAX Accelerator Program

At the JavaOne Conference in San Francisco, TIBCO announced the AJAX Accelerator Program.

Developers who register for the program at www.tibco.com/mk/2005/gi.jsp will receive priority access to the next release of TIBCO General Interface, version 3.0, prior to its general availability later in the year. In addition, developers will benefit from invitations to exclusive briefings, educational seminars and developer community events with AJAX experts.

Available today in version 2.4, TIBCO General Interface gives browser-based applications the features and performance characteristics found in thick-client GUIs. Leveraging the asynchronous communications, javascript, and XML (”AJAX”) capabilities present in common Web browsers, TIBCO General Interface allows developers to easily deploy rich Internet applications without dependency on applets, plug-ins or installation of client/server frameworks. Using TIBCO General Interface’s breakthrough development tools — also built using TIBCO General Interface — developers can rapidly create powerful solutions with drag and drop speed.

Read more here.

Atlas : AJAX Framework

By David Worthington, BetaNews

Microsoft Cleans Up AJAX with ‘Atlas’

BetaNews has learned that Microsoft is preparing an object oriented JavaScript framework for AJAX developers code-named “Atlas.” The first Atlas bits will arrive at PDC 2005 in September following the 2.0 release of ASP.NET, and provide developers with new options for creating Avalon enabled browser applications.

Read more …

Finally something promising from the MS camp. Lets just hope its something worth using and not yet another MS’ bloated framework. It also bring in mixed feelings, I’m happy that they’re doing something to simplify life yet at the same time the hidden mean business motive remains a mystery and somewhat bothersome. (When did THEY start playing nice?)

New name, new game!

I’ve been reading a lot about the shortcomings and pitfalls to watch out for with AJAX. Some of the issues are real, others are doubts created in the mind when we shift from one paradigm to the other. We’re so used to the old one that fitting old concepts in the new frame seems disorienting.

The point being, this is supposed to be another way of doing things. Do NOT mix up what you have amassed so far. In order to create a real web application, that is more or less based along the lines of a console application, we need to import lessons from the “console camp”. eg. the concern about breaking the back button seems pretty much a “new tech with old concept” problem. This is an entirely different application architecture. So in order to render the UI, rather than a normal browser window, use a controlled environment, such as a window without a few toolbars. The users have to know that they are no more dealing with web pages anymore but the application in its entirety.

Then comes the request queue concern, assuming that the network is not reliable, think of the requests in terms of messages between application tiers. Each message is assigned a unique ID and a timeout is set on the client side. This is something Harry had written about some time back. Send no more that one message out at a time. The system must work in a linear fashion as far as the request queue processing is concerned. So in this case the next message isn’t sent out until the first one has been acknowledged and its corresponding data recieved.

Then comes the implementation problem. I have come across some websites that have poorly implemented AJAX. Yahoo!’s avatar system is one such example. There seems to be a good use of the xml request object and DOM and CSS but what about the notifications? The user even in this case, has to wait, even if it be for a short while (Dial-up users like me know). But if the user sees no refreshing, no status messages, no notifications etc they tend ot get worried. So whenever you implement it, make sure real-time notification is a part of your application architecture.

Finally, addressing the session issue. I believe that this method is best suited for non secure data transfer since cookies are the only session management option. Contradicting Harry’s post about sensitive information transmission security, there is some data you just never store in cookies, why must exceptions be made for AJAX.

The idea is to use the framework the way it is supposed to be used. We don’t use MFC for embedded systems’ programming do we?

AJAX: The Starbucks Factor

Via Neil Kandalgaonkar ran into Starbucks Does Not Use Two-Phase Commit which is one of the essay’s referenced in Joel Spolsky’s new book The Best Software Writing I: Selected and Introduced by Joel Spolsky.

When you place your order the cashier marks a coffee cup with your order and places it into the queue. The queue is quite literally a queue of coffee cups lined up on top of the espresso machine. This queue decouples cashier and barista and allows the cashier to keep taking orders even if the barista is backed up for a moment.

…

By taking advantage of an asynchronous approach Starbucks also has to deal with the same challenges that asynchrony inherently brings. Take for example, correlation. Drink orders are not necessarily completed in the order they were placed. This can happen for two reasons. First, multiple baristas may be processing orders using different equipment. Blended drinks may take longer than a drip coffee. Second, baristas may make multiple drinks in one batch to optimize processing time. As a result, Starbucks has a correlation problem. Drinks are delivered out of sequence and need to be matched up to the correct customer.

Sound familiar?

The trail leads on to Will the Real Asynchrony Please Stand Up? and a book called Enterprise Integration Patterns. Some food for thought…

AJAX: telling it like it is…

Marcus Baker, author of the excellent PHP unit testing toolkit Simple Test lays it on the line: Listen kids, AJAX is not cool;

Marcus is goes straight for the jugular, playing the “it’s the network stupid” card and puts it in far more succinct terms than I’ve been cautiously trying to do in some of these blogs.

The more I think about it, the more it’s clear that some kind of delaying HTTP proxy, that I was suggesting here, is badly needed to make people see how badly AJAX can suck when you inject a little latency - AJAX@localhost is always going to look good.

Marcus mainly refers to hooking up UI components a user can interact with directly with AJAX. There is another way to go with AJAX, which is suggested in Ajax: It’s not all about XMLHTTPRequest (part I) and part 2 - namely start treating Javascript as a real runtime, occasionally “syncing” with the server to prevent data loss. In theory that’s probably the right way to go but it raises a whole bunch of new issues, from redefining the notion of a session to whether Javascript is really a robust platform for application development (see point 3 then follow that up by reading Javascript sucks vol. 1). Marcus highlights the lack of mature testing tools for Javascript (or even the lack of an environment to automating testing of Javascript in), which is part of this picture of Javascripts deficiancies.

From where I stand, Javascript is today where it should have been about 5 years ago as people were discovering DHTML - you can now write code which has a pretty good chance of running under all the modern browsers for the sake of neat web page gimmicks. But what Javascript isn’t is a sane environment for building MVC applications where the data model is available courtesy of AJAX.

Things like GMail and Tibco General Interface are exceptions, not the final destination. With enough money and manpower practically any technological pig can be made to fly - that doesn’t translate to the reality of small web shops building apps for SME’s.

Of course this not going to stop anyone from trying - we’re talking holy grail here. But what is worth remembering is if you decide to go AJAX, realize that you’re significantly increasing the risk that your project will “fail”. Don’t try it where real money is involved. As Marcus puts it;

When you write AJAX applicatons you drive a horse and cart through one of the most successful metaphors of all time.

Javascript static variables

Something I find strange about Javascript;

[code lang="javascript"]
function Foo(){};
Foo.prototype = {

bar: [], // or ‘new Array()’ or ‘new Object()’

set: function(val) {
this.bar.push(val);
},

displayBar: function() {
alert (this.bar);
}
}

var foo = new Foo();
foo.set(1);
foo.set(2);

// Alert displays 1,2
foo.displayBar();

// Destoy the object
foo = null;

// Create a new one…
var x = new Foo();

// What does this display?
x.displayBar();
[/code]

By declaring the bar property to be an Array, it seems to make it static to values assigned to the array are in effect updating the class definition - later objects inherit those values. The same works for Objects and both Moz and IE behave the same way, so this would seem to be a feature. The only way to really free the memory is to modify the prototype e.g. Foo.prototype.bar = null;

Anyway haven’t seen it discussed before before - perhaps a useful feature or otherwise a path to eat up memory and forget to free it.

Async Requests over an Unreliable Network

The biggest void in the AJAX discussion, IMO, is how network and server availability affects XMLHttpRequests. I can only guess this void is a result of skill set - if you’re hot with CSS is issues relating to UI design, chances are you’re less fluent in the fine print of HTTP or used to thinking in terms of writing fault tolerant clients to remote services.

That gets further compounded by developing on localhost where you don’t get to see the impact of synchronous requests, for example, when the network or remote server is taking a break.

Question Time
Good news is there’s more discussion of such AJAX implementation details starting to appear, beginning with some excellent insight from Weiqi Gao in questioning AJAX and some concerns about the impact on development strategy from Bjorn Schott: AJAX: redesign your PHP applications?, with follow up from Marco Tabini in the anatomy of an AJAX framework. Yet more good stuff to be found in Ajax: It’s not all about XMLHTTPRequest (part I) and part 2.

Not Invented Here

Meanwhile one thing I keep seeing is comments like this one - not invented here - bloated: write my own. To some extent, fair enough and happen to like Alexander’s use of XMLHttpRequest because he has paid some attention to the impact the network may have on it.

But the point is, doing a “Hello World!”, directly against the ‘raw’ XMLHttpRequest API on localhost can be done with only a few lines of code. Unfortunately there’s more glue required before you can safely deploy it in the wild in a way that won’t drive users mad. And once you’ve repeated that glue a few times in a few places, you starting evolving your own “bloat”.

Issues with ASYNC requests in Live Environments

Getting back on track, there’s probably two major issues that occur to me with ASYNC requests, which aren’t solved “by default” by the XMLHttpRequest object.

1. Dealing with Delay: if the network or remote server is taking it’s time, how does that relate to your AJAX application?
2. Response Sequencing: network (or server) latency may vary over time. That means responses may not return in the order they were requested.

1. Dealing with Delay

In AJAX mistakes, Alex Bosworth makes reference to the problem with points 1. and 4.;

1. Not giving immediate visual cues for clicking widgets.

If something I’m clicking on is triggering Ajax actions, you have to give me a visual cue that something is going on. An example of this is GMail loading button that is in the top right. Whenever I do something in GMail, a little red box in the top right indicates that the page is loading, to make up for the fact that Ajax doesn’t trigger the normal web UI for new page loading.

4. Blinking and changing parts of the page unexpectedly

The first A in Ajax stands for asynchronous. The problem with asynchronous messages is that they can be quite confusing when they are pop in unexpectedly. Asynchronous page changes should only ever occur in narrowly defined places and should be used judiciously, flashing and blinking in messages in areas I don’t want to concentrate on harkens back to days of the html blink tag.

Alex is arguing this from the standpoint of an end user or a UI designer. Will aim to extend those points here with a practical step to help this.

First think it’s important to understand the effect by seeing it happen. Using the same Python server script from here, I modify the client script slightly to get it to place async requests instead or synchronous;

[code lang="xml"]

Do it!

[/code]

Now if you save this as async1.html under my Python server’s directory (read this one again for longer instructions), and try clicking on that “doIt!” link a few times, you’ll see the sort of wierdness a delay on the server can cause.

Sometime you’ll get a response immediately. Other times it will take ages. Sometimes you’ll get this in your Javascript console (assuming Firefox);

[code]
Error: uncaught exception: [Exception...
"Component returned failure code: 0xc1f30001
(NS_ERROR_NOT_INITIALIZED) [nsIXMLHttpRequest.send]”
nsresult: “0xc1f30001 (NS_ERROR_NOT_INITIALIZED)”
location: “JS frame :: http://localhost:8000/async1.html
:: doIt :: line 42″ data: no]
[/code]

That last one is caused by calling send() on an XMLHttpRequest object which is already processing an existing request. Will get to dealing with this problem in a minute…

Need for Tool: would really help people see the impact of latency on AJAX applications for themselves if there was tool to “slow” the network down. Any takers?

From my angle the easiest way to do this would be running a local HTTP proxy, through which your browser requests are tunnelled, and the responses are delayed by a small sleep() in the proxy.

Took half a shot at this by adding a filter to WebCleaner. Unfortunately WebCleaner has some internal mechanism to terminate connections which are taking too long, which killed my hack and my free moment. There’s a useful resource here on Python HTTP Proxies, some of which should be easy to hack. Would also be fairly easy to do with Perl’s HTTP::Proxy but a little messing in that area suggests that’s a *Nix only solution.

Anyway, the above example, if you try it, should give you a feeling for the sort of problems a delay can cause with async requests. The browser not longer “locks up” as it did with the sync requests, which is good, but the user get’s to keep on clicking stuff while wondering vaguely when the result will arrive.

Parting of solving this issue is giving visual feedback to the user - some kind of “in progess” status. But that’s not all - how long to you want to keep telling a user that they should keep waiting? If you’re not careful it could be in progress for a long long time - if the server delivers something like an HTTP ‘Content-Length’ header which is erroneously longer than the actual content you send, this could happen. To the end user, it’s likely that after a given number of seconds the request no longer bear relevance to what they’re doing - they’ve moved on to clicking other things and may be especially freaked out if a response shows up when they’d given up on it.

Timing Out

The usual approach, in other environments, where HTTP is being using is to implement some kind of timeout. If you’ve worked behind a corporate HTTP proxy, you’ve no doubt run into HTTP 504 status codes, where the proxy basically gave up trying to reach the web site you wanted it to.

Meanwhile most socket client APIs provide some kind of timeout setting you can control programmatically, like PHP’s fsockopen(). In fact it’s strange that XMLHttpRequest fails to offer this, but it’s fairly easy to add.

Uncaught Exception

Before adding a timeout capability to XMLHttpRequest, first going to solve the problem with that exception up there.

The fundamental problem is you can’t tell one XMLHttpRequest object to do two things at once and that’s solvable by using multiple instances of it, rather than the single global instance in the example above. In other words just create a new one whenever you need it. A note of fear and loathing here - have heard and possibly experienced strange things when lots of XMLHttpRequest objects are at work together. Have yet to really track it down - the exact circumstances / browser versions etc. unknown - whether it’s a garbage collection issue or what, I don’t know. Just be afraid

So it might be you want to re-use an XMLHttpRequest object once it’s finished the current request, for the sake of a little efficiency. Solving this problem also makes timeouts easy to implement. So I can do it with a function that accepts an XMLHttpRequest instance and checks it’s ready state;

[code lang="javascript"]
function callInProgress(xmlhttp) {
switch ( xmlhttp.readyState ) {
case 1, 2, 3:
return true;
break;

// Case 4 and 0
default:
return false;
break;
}
}
[/code]

Actually documented this here.

Now before calling send(), I can look first to see if the object is busy e.g.

[code lang="javascript"]
if ( !callInProgress(xmlhttp) ) {
xmlhttp.send(null);
} else {
alert(”I’m busy. Wait a moment”);
}
[/code]

Aborting a Request

The XMLHttpRequest object also comes with an abort() method, to terminate the current request.

Only problem with abort(), as I remember (exact details purged from head and no desire to re-create circumstances) is if you call it on an object which isn’t processing a request (readyState 0 or 4) - weird things happen.

So the above callInProgess function can be useful.

Implementing Timeouts

Knowing all of the above, timeout can now be fairly easily implemented using window.setTimeout();

[code lang="javascript"]
var timeoutId = window.setTimeout(
function() {
if ( callInProgress(xmlhttp) ) {
xmlhttp.abort();
}
},
5000 // Five seconds
);
[/code]

One catch here though, which I failed to mention here but implemented in JPSpan, is if you’re going to re-use the XMLHttpRequest object for another request, you need to remember to remove the timeout once the first request is completed, using
window.clearTimeout(), otherwise it will turn up to bite unexpectedly on a later request.

In the example I’ve been using, that would probably mean adding it to the callback function e.g.

[code lang="javascript"]
// Callback
function handleResponse() {
if ( xmlhttp.readyState == 4 ) {

window.clearTimeout(timeoutId);

alert (xmlhttp.responseText);
}
}
[/code]

The only problem now is how we inform the end user (or the code that’s waiting for the response) that the request was timed out? Right now we’re just killing those requests quietly. Users probably need to know in some instances (like when they clicked “Save”) while code might like a chance to react, such as terminating that progress indicator or re-attempting the request.

Simply raising an exception from inside the anonymous function I registered with window.setTimeout() won’t work because there’s nothing in a position to catch it. Easier is probably calling some error reporting function e.g.;

[code lang="javascript"]
function reportTimeout() {
// Fairly inexact but still something
alert(’A request was timed out. Taking too long’);
}
[/code]

Now the timeout function becomes;

[code lang="javascript"]
var timeoutId = window.setTimeout(
function() {
if ( callInProgress(xmlhttp) ) {
xmlhttp.abort();
reportTimeout();
}
},
5000 // Five seconds
);
[/code]

So timeouts are now possible but the quantity of extra glue is starting to rise…

2. Response Sequencing

Need a break from typing so will pick this up in detail some other time but consider this example which came up here;

Let’s say I’m showing a catalog that someone is shopping in, and asynchronously updating their shopping cart when they add items, sending an XMLHttpRequest message to the server and having it update the shopping cart display. Now let’s say the user wants one more item, adds it to the cart, and quickly clicks the checkout button… which one gets through first, the shopping cart add or the checkout?

It’s not safe to assume that your callback functions will be trigger in the same order that requests were made. If the “addToCart” operation takes a long time for the server to process, while “proceedToCheckout” is quick, it could well be that your “proceedToCheckoutHandler” function get’s called first.

Solving this needs some real glue, which I don’t have right now. Off the top of my head it needs some kind of queue to allow the responses to “fire” in the right order as well as a temporary “callback cache” which will likely need some tricks with Javascript closures.

More some other time…

FEATURED INFORMATION

In the recent years, webmasters are more aware about their websites search engine ranking and they are continuously making effort to improve it. Now many business web hosting companies provide the facility of search engine placement along with their regular services like unix hosting and virtual dedicated hosting etc. Also doing affiliation with online training authorities like cisco training and indulging in pay per click can not only increase ranking but also revenue.

php | architect PHP & AJAX presentation

Marco Tabini of php | architect has posted a recording of Joshua Eichorn’s Building Dynamic Applications with PHP And AJAX. This is provided in a two part series of flash recordings of the talks (complete with live chat transcripts).