jutopia - Designs for remote calls in Ajax

[]

Designs for remote calls in Ajax

[ tirsen ] 06:37, Tuesday, 16 August 2005

I’m pleased with how the best practices of doing remoting are emerging in Ajax. Most Ajax libraries have ditched the RPC approach to remoting and are instead using a very specialized form of distributed computing.

Please allow me to explain…

Simple call, simple return The simplest form of remote interchange in Ajax can be seen in for example the in place editor of photo titles and descriptions at Flickr (here's a demo of an upcoming control in script.aculo.us that implements this, be warned though it still very much pre-release quality). It’s a simple REST style call, a url is constructed with the updated title or description as a simple parameter. Any return value is sent verbatim in the body of the response and used directly by the JavaScript code in the browser. This can be compared to an ordinary RPC call.

Simple call, snippet returned The next step in complexity is when a more complex value needs to be returned (like as a list of values or multiple named values). An example of this is the script.aculo.us auto completing text fields. The text is once again sent in simple REST style with the parameters encoded in the URL. The result of the call is where the interesting bits come in, instead of returning a serialized data structure that needs unmarshalling and interpretation on the client side the server simply returns the HTML snippet of the result pane. All the client needs to do is use the browsers built in HTML parser (the result is in fact already parsed by the XmlHttpRequest) and update the DOM of the result pane. The remote call is completely adapted to the client, which is almost the opposite of CORBA-style remoting or web services where the remote interface is supposed to be completely generic and it is the client responsibility to figure out how to handle the result.

Simple call, behaviour returned The last approach is even more interesting (and could be called agent oriented by the widest stretch of the definition). It’s used a little bit by Gmail and is implemented by the evaluate_remote_response in Ruby on Rails. This technique also encodes arguments as URL query parameters but the result at this time is neither a simple value nor an HTML snippet, it is a JavaScript snippet which is directly evaluated by the client! The server can return any number of HTML snippets, execute graphical effects, update different cells in a table, navigate to a different page and so on.

Is this good? I can hear some of you protest: “But the client becomes tightly coupled to the server! This is horrendous!” A lot of people feel that there are compelling reasons to make an abstraction layer along the same lines as the distribution layer.

There are reasons to do this, but personally I don’t buy it; the only way to effectively handle a distribution boundary is by specifically designing both sides of the boundary to accommodate to each other. Ultimately designing the remote interface directly according to how the user will interact with the application. One single user transaction may span several conceptual transactions with the system, in a traditional RPC-style remoting design this would mean multiple remote calls which is quite ineffective. In Ajax it would be one single call using one of the three methods as described above. Much more effective.

Another reason for making the remote interface generic and system-driven (as opposed to user-driven) is because in a traditional client/server scenario there’s much less control of the client. The server may for example need to support multiple versions of the client or different clients at the same time. This is not the case in an Ajax-enabled web application, the server has a pretty strong control over the client. The browser does cache some stuff (according to specification by the server) but nothing is ever installed on the client. There is only ever one version of the client and when the server gets upgraded so does the client.

Finally remember that this is not about integrating two different systems, it’s one single system with a distribution boundary in the middle. If we're talking system-to-system integration then CORBA, EJBs, web services, messaging, SOA or whatever's the latest trend are all valid candidates.

The approach used by many Ajax applications also means that a lot more of the presentation logic executes at the server. Paradoxically this stems from the fact that web applications in the end actually don't have very strong control of the client. There are a lot of differences between different browsers and in terms of security the server can never depend on something getting executed in the browser. Instead the best practice seems to be to delegate a lot of the logic to the server that returns pre-baked responses that require very little logic to handle on the client.

The end result is that many Ajax applications has an extremely tight collaboration between client and server, so tight that the distribution boundary is in fact conceptually blurred and the conceptual presentation layer could be said to run both on the server and the client. Or in other words...

The conceptual division between presentation logic and business logic does not coincide with the physical separation of client and server.

So are Ajax developers guru software designers for coming up with this? I don’t think most Ajax developers are aware of all this. The good ones are simply pragmatic programmers that are more focused on the user experience than theoretical mumbo-jumbo like this article (which kinda explains why PHP could've ever been so popular, the horrible language that it is). So the special approach to remoting that is used in many Ajax applications has developed in a much more pragmatic (and I would say healthier) fashion than with for example CORBA or Web services. If you permit me to interpret and extrapolate this a little bit then I would even say that this could mean that Ajax web applications may soon become a very serious competitor to desktop applications. The best practices and frameworks in the "AJAX community" is simply better positioned to delivering compelling applications instead of complying to various pretty theoretical dogmas.

So, well, I’m pretty pleased about it…

Post scriptum: What about more complex calls? All these designs use a simple REST style call from the client, which only allows for simple values or name/value encoded pairs. I have yet to observe a more complex call from the client "in the wild". There's the drag-and-drop list reordering callback in script.aculo.us which is essentially a list of ids but it's still pretty simple. If anyone has a good example of a more complex call I'd love to hear about it!

Post scriptum 2 Sorry for mainly using examples from script.aculo.us, it's simply the Ajax framework I know best.

Hey Jon,

This is an interesting summary. I think it is a shame that a lot of the AJAX implementations come up with their own form of distributed computing. It reminds of the early days of SOAP when different vendors tried to do it their own way, but the industry at one point managed to come up with a standardized way of client/server interaction.

I suspect doing something similar with AJAX would have tremendous benefit for the end users. Imagine if there is a standard client-server XML protocol for all AJAX apps. This way the end-user would have a great benefit to avoid a vendor lock-in situation.

Our product follows a traditional RPC approach. We provide a client side library that lets you bind to any server-side object using the same API. A result of the binding process is a javascript proxy that has the same methods as the remote object or service. Invocations on the proxy object can be syncronous or asynchronous. The same types of arguments in the formal method signatures are supported on the client side (primitives, strings, arrays, complex types). One of the main goals we set forward for our product is to bridge the client/server gap and bring a remote object as close as possible to the client side. The idea is that the server-side guys focus on the core application domain and expose it via set of objects where individual methods do very specific business-related operations. The client-side developers focus on the presentation-tier and know how to bind to a remote object and use it. I do not believe that a middle tier has any value with rich internet apps. Would be curious to hear your take on this.

cheers,
Terry
http://www.themidnightcoders.com

--Terry Nisenbaum, August 17, 2005 04:05 AM

Helly Terry,

Unfortunately I would have to say that I disagree with the approach you are suggesting.

First of all, I don't believe it's advisable to have different teams working on different sides of a physical distribution boundary. Instead if possible I suggest the direct opposite. In some situations there might be organizational or other reasons where this is not possible but this is usually not the case when you are writing a web application.

What I'm trying to say in my article is that the Ajax developers have gotten it right. They completely adapt the server side to accomodate for the client side. Directly down to returning exactly verbatim what the client needs. No marshalling, no IIOP, no XML-RPC, no SOAP, no OSF DCE RPC. Just plain old text, HTML snippets or JavaScript snippets.

I fail to understand the value for end-users when the browser part of a web application use a standard protocol to communicate with the server part of the same application (disregarding the already standard HTTP). How would it benefit them to "avoid the vendor lock-in situation"? Would the end-user benefit of being able to use a different client to the same server? Maybe, but I just fail to see it.

Good luck with your product!

Cheers,
Jon

--Jon Tirsen, August 17, 2005 08:10 AM

Jon,

In my experience it takes 2 completely different set of skills to create a kick butt UI and to capture core application domain functionality in a set of reusable services. Traditional apps require at least 3 tiers - UI, middletier and backend. With the RIAs the middle tier is no longer needed (at least with our product). I have never seen that a ASP/JSP or HTML developer would work on the backend implementation and vice versa. In fact, if it would ever happen, the project is in trouble right from that point. If you picture large established service providers like Ebay, Google, Yahoo and Amazon, they captured the core of what they do in a set of services. The backend services can care less what the UI does internally, as long as it can grab data and execute operations on nicely defined server-side components.

In my mind, and we proved with *numerous* deployments of rich internet apps, what the client ideally needs is data, no snippets of html or javascript. The *rich* client is in charge of the presentation and the server should not be dictating what to show with the only exception of data security or navigation.

As for the vendor lock-in, it is not very different than with SOAP. It is way to early to apply to AJAX, but as soon as we see WebLogics and WebSpheres of this world announce support for AJAX, there will be a need for a standardized client/server protocol. HTTP is just a transport, it can carry binary or text data, the issue in question what that data on the wire looks like. Will a user that decided to go with company X to do AJAX messaging be able to switch to company Y without any changes on the client side?

cheers,
Terry

--Terry Nisenbaum, August 17, 2005 05:19 PM