Ajax forest, Remote Scripting trees
March 24th, 2005It reminds me of the Big Honey Hunt where following a single buzzing bee turned into a roundabout adventure that never quite seemed to get to the source but ended up stirring up the entire bee community.
My sentiments match those of Dougal who is simply glad enough that developers have discovered these concepts, however late in the game and by whatever name (mind you, I’m fully behind Dougal’s ARSE …umm, strike that).
So it’s time to cut through the crap and get some work done with this stuff.
AJAX is an acronym for Asynchronous JAvascript + XML. Ok, now that I’ve told you that, forget you ever heard it. Ajax (proper case) has already come to represent a wider concept. The concept is this: Load up and render a webpage, then remain at that page while scripted routines make background trips to the server for data that is used to update the page in place by re-rendering and or hiding/unhiding portions of the page.
Now that we’ve got that settled, let’s break the concept down into some functional parts to see where the convoluted discussion’s apples and oranges lie:
- Presentation
- Invocation
- Message Encoding
- Transport
The Presentation layer manipulates the display of data using whatever technology is available. DOM manipulation is the current way to do it, but older methods used the various flavours of DHTML available from the browsers at the time. Keeping up with the current set of browsers and their rendering quirks is pretty hairy.
Invocation can be object oriented or procedural depending on the API wrapped around the transport. Asynchronous or synchronous invocation depends more on the transport implementation. My JSRS library for instance only offers asynchronous communication - a limitation imposed on it by the transport layer I needed to use to work across the different browsers available at the time. Microsoft’s Java Applet based Remote Scripting could do both sync and async, and provided both an object and a procedural interface. The XMLHTTP transport offers both async and sync and you can wrap it up how you like.
I prefer to remain lightweight in my message encoding, sending strings back and forth, perhaps encoding structures into Javascript code, a trick I first saw in Microsoft’s RS (the “uneval” function that serializes a javascript obect into the code to reconstitute it). You can get some quite efficiently sized packets with low overhead. Many people prefer to use XML either because their particular development space is all about XML or in order to raise the level of abstraction at the cost of API internal complexity. XMLHTTP etc is then used for the encoding/decoding.
There are various transport methods that allow a browser to send and receive data without page refresh. The lightest one I use is to create an image object and set its source url to a server-side script that takes the querystring parameters, performs work, and returns a string via a cookie, then sends an empty document as the image. Before XMLHTTP was widely available, various hidden iframe and layer methods were used in order to actually hack functionality out of browsers that had not been designed with arbitrary data transport in mind. Other methods involve returning Javascript to the browser for execution. I use XMLHTTP now because I can use it synchronously, which was not possible in Javascript alone because of the lack of a non-blocking sleep function (you go into a tight loop to wait for a result and CPU runs to 100%). Previously would need Java or Flash or an ActiveX control to get that level of control. Now the prominent browsers have their own versions of XMLHTTP with which you can get arbitrary data in either sync or async fashion.
It should be apparent by now that we’re talking about a concept that has remained constant since as early as 1998 and a set of techniques with which to accomplish the task which have evolved over time around the capabilities of the tools at hand. The method used for any project has been selected as a result of the project’s choice of platform and design parameters.
When I get a chance, I’ll try to compile a list of links. In the meantime, use your favourite search engine to look for “Remote Scripting” for some of the historical solutions, and “Ajax” for some of the new stuff.
Other technique to use is WebService behavior ( and yes, I know that is an IE only solution) but in many intranet settings this is a very viable solution. Xml is great way to package up the data and return the result set. I am not sure why you are against asynchrous methods. I tend to think the working asynchrously is a real plus. Xmlhttp is fine, but if you work with web services, you need to twist up some soap header stuff, a minor inconvience.
To the guys who talk about doing this stuff for 5 years, I contend I was doing far longer than that. With classical asp and com, we used Remote Data Spaces to instantiate COM objects on the server, this was when roundtriping with the browswer was bad. Horrible from the stand point of security, tons of client side code required as well. When asp.net started, we just accepted the browser round trip, but hey, the pages were faster and it was a lot easier to code.
For me, it was when I got my first look at gMail and I wanted to know how the google engineers got the incredible speed. Google suggests again, very cool, brilliant UI and the one that capped it off for me was Google Maps.
When you start to play around with these techniques, somehow the browser space seems richer than winforms. What we have today is incredible speed and responsiveness in the browser. The other partthat is cool is the way the processing is distributed, servers go back to being servers finely and why not tax the clients machine, it’s most likely at idel anyway. In some ways, I can see ajax implementations that work with SOA. The xml packages can be seen as contracts, the webservices can comsume this packages and deliver resultsets back the ajax engine.
Here is another part that gets interesting. With SQL 2005 you can now create web services directly within the SQL server process, this means I could do directly from database to client without having to reprocess and repackage the information. I can only imagine what the performance will be like.
I am taking a very different look at web developement these days. Ajax is a cool name. This stuff is going to be huge.
I’m not particularly against asynchronous methods - they have served me well. Coming from a procedural background, I find that synchronous operation is more natural for me and fits my train of thought better.
I suppose really that since I was constrained against using it, I found myself limited. Now that I can work either way, I’ll use each technique to its advantage.
I would argue that all the hype around Google GMail and GMaps is well deserved, but that doesn’t make the average app developer any wiser. This stuff is reams and reams of code put together by the best in the business. For average developers to build UIs that are as slick and efficient as that is not a reality. Will NEVER happen. Not without browser consolidation and at least some hopes that browser will work consistently across vendor implementations.
Higher level services like Ajax are a step in the right direction, but why stop there? Why for example isn’t there a standard SOAP implementation for Browsers? With all this focus on SOA and Web Services and for ease of creating the backend WS is still one of the best options. There are two sides to this equation and hte server side needs to be addressed as well. The last thing we want is people coming up with their own proprietary transfer protocols to ship data around the wire, reinventing the wheel over and over again.
Instead people fart around with yet another new standard to pile on the other 4-5 letter acronyms.
Hi, Brent.
The real problem I have with all this acronym horse manure is people are using it to sell more magazines, conferences, and books (and even “products”) rather than providing real new technology based on innovation. We all know that XMLHTTP has been around since IE 3.0 and the first big “AJAX” Implementation was Outlook Web Access. That was a very long time ago, by Internet standards…
Recently I found out that you can’t even use AJAX (the foaming cleanser?) to request a lousy RSS feed in Firefox, unless it comes from the same site as the page. Shot themselves in the foot a bit, dontcha think?
It is interesting to compare your list: Presentation, Invocation, Encoding, Transport with the PEPT architecture http://haroldcarr.net/pept/ : Presentation, Encoding, Protocol, Transport. PEPT is an architecture understand and/or build remoting systems. It shows that the programming model at the Presentation level can be procedural, object-based or a messaging API. Regardless, the rest of the infrastructure is essentially the same: Encoding: the data send/received must be endoded; Protocol: the encoded data must have added “bits” that frame the data and give the intent of the data (and add metadata); Transport: the encoded/framed data must be sent from one location to another.
I responded to Harold on Phil Windley’s blog before noticing his comment here. Here’s a quote:
I struggled a bit before I decided on “Invocation” rather than “Protocol” because I wanted to express the concept of programmatic interface with both data passing and sync/async and at the same time avoid any confusion with wire protocols that describe what happens at lower layers.
Also, I put Encoding below Invocation in the layered model in the expectation that implementations would usually pass objects or values in their language-native form and the API routines would then encode/transport/decode to the other side and present results in the language-native form of the remote environment.
That is, the encoding is transparent to the caller and the called routine.
This is how SOAP works when abstracted well. I write a server-side routine in PHP that returns an object, describe it properly with WSDL, and a C# or VB.NET client’s API builds a native proxy object at the other end.
Harold, I note from your curriculum vitae that you created and patented PEPT sometime between 2001 and the present. Do you have a patent number I can refer to?
For me, the “programatic” concerns are contained in the Presentation block (BTW: PEPT is NOT a stack architecture - the four main pieces can all interact with each other if need be - e.g., fragmentation). That is where PEPT provides either a typical RMI interface or a typical messaging (e.g., JMS) interface. RMI is generally synchronous but certainly allows for ONEWAY calls. JMS is generally asynchronous.
Protocol, in PEPT is kind-of dual natured: PEPT considers an internal protocol to be any steps done in the sending or receiving side to route the message. That includes handling the wire-level protocol details and waiting for a reply or fire and forget.
I completely agree the “encoding is transparent to the caller and called routine”. One of PEPTs motivations was to show how to present higher level APIs to remote system users while enabling the lower-level infrastructure dynamically (per-invocation) or evolutionarily (e.g., new standards) switch EPTs (Encodings, Protocols and Transports). Another way of looking at this is we really don’t need a JAX-RPC and an RMI (or RMI-IIOP) programming mode. We just need two: one for generic RMI (or RPC) and one for generic messaging.
There are three PEPT patents pending:
10/677,434 Oct 2, 2003
10/863,094 Jun 8, 2004
10/954,861 Sep 30, 2004
Regards,
Harold
Thanks for the clarification, Harold. The per-invocation switching of EPTs sounds interesting.
Syncronous use of the xmlhttprequest inside IE is a very bad idea, it locks the UI whilst waiting for the request - which is pretty much the opposite of giving a responsive UI that people are now wanting to do.
There are also a few lock-up bugs in the implementation when running under IE and it’s making simultaneous requests (for images etc.) - the 2 http requests allowed block each other.
The astute among you may notice that I’ve removed a particular comment and my reply from the beginning of the thread. Short story: anonymous commenter was rude, I was snippy in response, no value added.
[…] Perspective (forest vs. trees) (more) […]