Summary
Two distinct approaches to Ajax application development emerged in recent years, each extending previous architecture models. As the two seem incompatible, you will need to make a choice.
Advertisement
When you hear the term Ajax these days, your first reaction might be highly interactive Web pages, and along with that the requirement to code at least part of a Web application in JavaScript to offer that interactivity. While there is agreement on what an Ajax application means, there is much less consensus about how a developer would interact with that JavaScript, or how to distribute display logic between client and server.
In recent months, we reported on Artima about several Java-centric rich-client frameworks that aim to completely hide a developer's interaction with JavaScript. Those frameworks encapsulate JavaScript into JSF components, treating JavaScript almost as an implementation detail hidden from the developer. Taking advantage of JSF's server-side rendering model, JSF-based Ajax frameworks render out a component's state to the client—along with any JavaScript that forms part of that component's state.
By contrast, the Ajax world is abuzz with several client-side component toolkits that take a different approach. Toolkits such as Dojo or Prototype not only expose JavaScript to the user, but make it easier to develop page-as-application type apps. The Dojo Toolkit, for instance, provides many APIs that mimic important parts of the J2SE API, such as collections and validators, in addition to UI widgets. Such an application would place not only display logic, but even some business logic on the client, and that business logic would be coded in JavaScript. Interaction with a server would be limited to situations where the client application must interact with external resources—for example to fetch data into the client, or to save a user's changes to data.
Because the JSF-based Ajax approach performs all rendering on the server, and encapsulates Ajax features into components, it seems to be an extension of thin-client computing, and is thus a direct descendent of traditional Web apps that render simple HTML on the server and then push that rendered component representation—HTML—out to the client. A more remote cousin of this approach is the Sun Ray thin client device that renders desktop images on the server, and pushes the rendered images to dedicated client devices. In both cases, the client is treated not much more than as a specialized display. The second approach, by contrast, is an extension of client-server computing that distributes an application's logic between client and server—only, in the Ajax world, the client is a programmable Web browser.
While both approaches are rooted in well-established practice, they take a markedly different philosophy to application development. Proponents of the thin-client approach mention incompatible JavaScript implementations in browsers, as well as the relative obscurity of JavaScript as a serious development language. They seldom mention whether the thin-client model would be preferred even if all browsers rendered JavaScript equally well.
While JavaScript is still a hard language to develop business logic in, a new version, EcmaScript 4, promises a fully object-oriented language not unlike Java, and because it's fairly standardized, browser implementations will in time converge on fairly compatible implementations. In addition, client libraries already mask most of the browser incompatibilities.
Client side proponents claim that their approach makes better use of local computing resources, and also results in applications that can replace traditional desktop applications, even without a permanent network connection (for example, Dojo, as well as Flex, have client-side storage APIs).
The diplomatic response to this dichotomy of approaches is that each design has pluses and minuses, and that each has its place. But because these approaches are not only different, but also incompatible—adding custom client-side JavaScript to a JSF-based component would venture outside that component's public interface—if you were to develop a brand new rich-client application, you would have to choose either the thin-client approach or the client-server model.
Rails uses a mix of the two: it uses prototype & scriptaculous, and it has RJS templates. These templates are Ruby-JavaScript templates: you generate Javascript with Ruby code. It's doesn't hide Javascript entirely, just the common cases. If you need more you can still uses raw Javascript, but the logic still happens on the serverside.
While JavaScript is still a hard language to develop business logic in, a new version, EcmaScript 4, promises a fully object-oriented language not unlike Java, and because it's fairly standardized, browser implementations will in time converge on fairly compatible implementations. In addition, client libraries already mask most of the browser incompatibilities
Not to put a damper on the Ajax hype, because it does bring some needed interactivity to web pages, but by the time EcmaScript 4 is out and prevalent in browsers, WPF/E will be out and it will be a whole new ballgame regarding doing real applications for the browser.
I'm going to make a prediction. Adobe or someone else will write a Java compiler that targets Flash 9 or above.
I got the suggestion from this article that someone might want to write business logic and run it on the client-side. This seems like a bad idea to me. Depending on your environment, that could be a a big security hole.
> I'm going to make a prediction. Adobe or someone else > will write a Java compiler that targets Flash 9 or above.
The semantics of Javascript are much better than Java's. Dynamic typing = good, closures = good, etc. Javascript has changed, it's much better now. The only problem is the standard library.
The Dojo Toolkit, for instance, provides many APIs that mimic important parts of the J2SE API, such as collections and validators, in addition to UI widgets. Such an application would place not only display logic, but even some business logic on the client, and that business logic would be coded in JavaScript.
Just because the library provides the facility for client-side validaiton, doesn't mean that the programmer is off the hook for server-side validation. Yes, this puts some business logic on the client side, but presumably it's there as a convenience to the user, and is also enforced on the server.
Note also that in Java MVC webapps, a lot of display logic currently resides on the server.
While JavaScript is still a hard language to develop business logic in...
Can you be more specific? This is a very broad statement. I don't see anything inherant in JavaScript (the language) that makes writing business logic hard.
a new version, EcmaScript 4, promises a fully object-oriented language not unlike Java, and because it's fairly standardized, browser implementations will in time converge on fairly compatible implementations.
I assume you mean that there is some planned language support for inheritance (which you can write for yourself relatively easily right now, not that you'd WANT to.) Other than that, OO in JavaScript seems pretty good to me.
Nestor’s rule of client-server separation: The closer information is to where the user is, the more interactive it is. The farther information is from you, the less control you have over it.
In an open environment like the web you can never trust the client and the ideal is to have an open web-service backend so the user can use his own custom client to send you data. It means that if you want the instant feedback interactivity of the rich client plus the benefit of separating the presentation from the data you will have to run all your validation and business rules on the client and then again on the server. To add insult to injury this is usually done in two different programming languages: JavaScript and Java (or C#, VB, PHP).
> Also, As you can guess, I'm all for the "make the client > do it" approach.
I don't know what you are working on but let's say you are writing a webpage for selling something. Do you put all the business logic to check that the price paid is correct for what is being purchased on the client?
> > Also, As you can guess, I'm all for the "make the > client > > do it" approach. > > I don't know what you are working on but let's say you are > writing a webpage for selling something. Do you put all > the business logic to check that the price paid is correct > for what is being purchased on the client?
Ignore this. I read the beginning of your post and you already answered it.
> Rails uses a mix of the two: it uses prototype & > scriptaculous, and it has RJS templates. These templates > are Ruby-JavaScript templates: you generate Javascript > with Ruby code. It's doesn't hide Javascript entirely, > just the common cases. If you need more you can still uses > raw Javascript, but the logic still happens on the > serverside.
I've been looking a bit into Rails' JavaScript support, and so far, it seems to have taken the approach shared by JSF as well, which is what you describe: Your domain model as well as the business and display logic reside an the server, and then Ajax calls are made back to the client to update the view in response to server-initated changes. Nothing of the domain model, or business logic, ever appears in JavaScript. Please let me know if my understanding is correct.
> I got the suggestion from this article that someone might > want to write business logic and run it on the > client-side. This seems like a bad idea to me. Depending > on your environment, that could be a a big security hole.
Why would that be a security hole? The client already has everything it needs to cause changes to the server-side state, even if only the thinnest display layer is entrusted to the client.
> Can you be more specific? This is a very broad statement. > I don't see anything inherant in JavaScript (the language) > that makes writing business logic hard. > > a new version, EcmaScript 4, promises a fully > object-oriented language not unlike Java, and because it's > fairly standardized, browser implementations will in time > converge on fairly compatible implementations. > > I assume you mean that there is some planned language > support for inheritance (which you can write for yourself > relatively easily right now, not that you'd WANT to.) > Other than that, OO in JavaScript seems pretty good to > me.
Yes, that was what partly motivated my post. The more I read about JavaScript, the more I see its strong points. However, I also see that many developers treat JavaScript as simply a way to add neat features to UI components, not as a way to design domain objects, for instance.
More important, many attempts at distributing logic to the client—any kind of client—seem to have failed in the enterprise application context so far. However, in domains such as games or telematics, the client is given more autonomy. That's perhaps because in games the client has to perform lots of processing in order to provide high levels of interactivity, and in telematics a vehicle may not always assume connectivity. I wonder to what extent those domains herald what's to come in enterprise applications. I don't know how many games are written in JavaScript, though.
And even if you model your domain objects in some client-side language, you still have to ferry those domain objects to the server for persistence, for instance. So you end up with two parallel object models, one on the client and one on the server (not to mention a third model, too, in the database).
Even worse, you may end up having three simultaneous representations of the same object - one on the client, one on the server, and one in the database. You have to somehow coordinate access to all three representation's state, as one one session, for instance. I think projects, such as Seam, attempt to deal with that.
> I've been looking a bit into Rails' JavaScript support, > and so far, it seems to have taken the approach shared by > JSF as well, which is what you describe: Your domain model > as well as the business and display logic reside an the > server, and then Ajax calls are made back to the client to > update the view in response to server-initated changes. > Nothing of the domain model, or business logic, ever > appears in JavaScript. Please let me know if my > understanding is correct.
I don't know much about JSF, but I think that's correct. Rails dynamically generates Javascript on the serverside which updates the page. So if you have a link with an Ajax call to someaction, someaction will return Javascript code, which will be executed on the client side.
> Even worse, you may end up having three simultaneous > representations of the same object - one on the client, > one on the server, and one in the database. You have to > somehow coordinate access to all three representation's > state, as one one session, for instance. I think projects, > such as Seam, attempt to deal with that.
For those who weren't there at the beginning, I recommend "Client Server Survival Guide"; it has a pretty good history.
The point here: C/S was invented to suck up [idle] cycles in a network of Engineering Workstations, which is to say, a distributable compute bound, but data sparse, environment. Back in the late '80s and early '90s, those of us writing for Unix databases driving VT-xxx (character mode interface) had an in-the-box C/S environment, with the display (client) memory mapped over RS-232. That is, editing of user input, on each keystroke if you wanted. AJAX is just an attempt to get back to that, albeit aided by the Pixel Fairy.
It's a very olde time interface; it just looks New to those Webbies who don't know that the Browser is just a Block Mode Interface, architecturally identical to a 3270 (it has a Display Edit Language that is vaguely JavaScript-ish); an even older interface which pre-dates the character mode *nix terminal.
C/S was never intended (because its designers knew better),to be used in compute sparse, database business environments.
The Idea that data integrity should be done on the client is a hard lesson, frequently learned. It looks like another generation will do so. sigh.
The architectural answer, of course, is code generation from a single repository. I, not surprisingly, vote for the database catalog. Model Driven Architecture fannies have other ideas.
> C/S was never intended (because its designers knew > better),to be used in compute sparse, database business > environments. > > The Idea that data integrity should be done on the client > is a hard lesson, frequently learned. It looks like > another generation will do so. sigh.
Are you suggesting that ensuring data integrity on the client is a plus?
Flat View: This topic has 26 replies
on 2 pages
[
12
|
»
]
Previous Topic
