My G+ Profile
« On the Virtues of a Well-Documented Schema | Main | Berkeley Identity Data Stolen »
Brent Ashley on Ajax and Remote Scripting
Brent Ashley “cuts through the crap” and talks about Ajax and remote scripting.
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
From brentashley: Ajax forest, Remote Scripting trees
Referenced Tue Mar 29 2005 08:35:49 GMT-0700 (MST)
As Brent points out, we’re not really talking about concepts or technology that hasn’t been available since 1998 or so. However, as with many things, it took some example to help us break out of the trap of thinking that a Web page always had to refresh completely.
This has really started to resonate with me lately. I’ve been reviewing some product for InfoWorld that have Web interfaces and they seem very clunky now whereas 6 months ago I accepted them as a fait accompli. I’m expecting more from Web applications now (and that will be reflected in my reviews). I think a few years from now, most Web applications will use dynamic rendering techniques as embodied in Ajax. For that to happen, however, we need better toolsets.
Posted by windley on March 29, 2005 8:33 AM
Comment from Harold Carr at March 29, 2005 10:07 AM
It is interesting to compare Brent's 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.
At Sun, we use PEPT in both our RMI-IIOP and our JAX-RPC implementations. In both cases we use it to dynamically switch encodings. In the RMI-IIOP case, when we discover we are talking between two ORBs with the same encoding capabilities we switch to Java object serialization rather than OMG CDR encoding. In the JAX-RPC case we switch between DocLiteral to FastInfo set (a binary encoding of XML).
From the programmer's point of view what they are most interested in is the data being sent/received - not the infrastructure. Ideally PEPT could supply a uniform programming model that presented a object-based or message-oriented API to the user. Then PEPT would handle dynamically switching EPTs as appropriate. In one case it might use "SOAP-oriented" EPTs. In another case it might use "CORBA-oriented" EPTs. And as future standards come along they could be seemlessly plugged in to the PEPT architecture without requiring changes to PEPT users code.
Comment from brent ashley at March 29, 2005 11:47 AM
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.
Comment from Harold Carr at March 29, 2005 2:54 PM
Brent,
I'll response in the comment section of you blog entry. See you there.
H