mvalente.eu/mv.* Heavy Mental Stuff

Path: mv.asterisco.pt!mvalente
From: mvale…@ruido-visual.pt (Mario Valente)
Newsgroups: mv
Subject: A Future Web Development Framework – Application Logic
Date: Sun, 07 Oct 07 21:21:21 GMT

There really isnt much to say about the middle component for
a 3-tier architecture (the business logic). You can of course
get into religious wars about which language it should use. This
is the component that usually generates all the talk precisely
because of the language issues. When discussing Django, Rails,
.NET, etc, people arent really arguing about what the application
(logic) server should do or what its architecture should be: they’re
just arguing on whether Python is better than Ruby is better than
Rails is better than PHP…

Me, although I currently favour Python, I am more of a syncretic
integrator: whatever solves the problem faster without spending
too much of my brain processing time (this immediately eliminates
Java.. LOL :-). Thats why I like some of the more recent options
available like Virtuoso or ActiveGrid that allow you to program
the business logic in a variety of languages (either choose one or
use all at the same time).

http://www.activegrid.com/
http://www.openlinksw.com/virtuoso/

Virtuoso, for example, by including the VM runtime for several
languages, is able to run code in Java, .NET, Python, Perl or PHP.

http://www.openlinksw.com/virtuoso/architect/vtechnical.htm

(nice graph there, maps some of my ideas nicely)

Nonetheless there are two points worth exploring about the logic
layer, whatever the language of your choice: how the logic layer
interfaces to the storage layer and how the logic layer interfaces
to the presentation layer.

The first problem I have already referred to in my previous post
about storage. Even though the usual interface is the SQL language
(due to the fact that 99% of the times the storage layer is implemented
using a relational database), nowadays most programming is being done
using an object-oriented language. Hence the object-relational impedance
problem and the proliferation of object-relational mappers (ORM), which
have become especially popular due to its use in Ruby-on-Rails ( more
precisely ActiveRecord).

As I stated in my previous post I dont think that this is the way of
the future. The indiscriminate use of the relational/SQL database is
way past due in an object/document/unstructured/hierarchical oriented
world and object-oriented databases should become the norm. On the other
hand I do have to admit that having my data closed down in some format
which is proprietary really bothers me a lot. Since I wrote my post about
storage, CouchDB has entered the radar of many people and it seems to
contain the basis for what is needed: a OO database that stores its
objects in a simple text format (JSON) with a REST interface.

http://couchdb.org/

The second problem (logic-to-presentation interface) actually mimics
the logic-to-data interface and it also has something to do with a later
issue (templating or view/controller). As in the logic-to-data interface
problem, where the logic level (ex: Perl or Python) currently embeds a
lot of data stuff (ie. SQL), the logic-to-presentation interface also
suffers from a lot of confusion, especially when you have templating systems
that allow you to mix code and presentation. PHP is a particularly bad
example of this problem.

This could be solved by explicitly denying the logic level to output
any kind of presentation code. Presentation level stuff (ie. templates
or view/controller) would be in charge of doing any presentation stuff,
getting all the data/logic from the applicatin server (through REST calls,
with data in JSON, XML, SOAP, whatever), with the application server being
explicitly prohibited from outputing any kind of HTML markup code (it just
wouldnt be taken into account or rendered).

What comes to mind as an example is an application server, using whatever
language, that would behave exclusively like TurboGears/CherryPy with the
jsonify decorator: you could call any URL in AJAX form and you would receive
results in JSON (or any other format), no HTML allowed.

http://docs.turbogears.org/1.0/JsonifyDecorator

Although I see no problem with the same server delivering both page
templates (ie. view/controllers) and logic (they are both HTTP after all),
that implies some discipline. An actual separation of concerns would
imply separate servers: one would only serve static pages (ie. templates)
and could be a standard HTTP server (Apache, etc) and the other would
only serve the processing results for received requests.

Event though I’m a bit agnostic regarding the choice of language for
your application server, I do have to state my opinion regarding current
trends and what I see as being the future endgame and the best choice.

Everyhing points towards a Javascript future.

http://steve-yegge.blogspot.com/2007/02/next-big-language.html

This is probably unpopular to say and there will be several voices
talking about Javascript’s speed. But the fact is that it doesnt make
much sense to use a language at logic/application level and then to
use another at presentation/template/view/controller level. Especially
when you take into account the current AJAX and JSON trends. You just
create aditional impedance when your doing stuff in Javascript at
presentation level (lets say field validation for example) and then
you’re encoding form fields into XML or POST fields, requesting some
processing from the application server which has to unmarshall the data
into whatever its format is, process it and remarshall the data back
into XML or JSON for delivery to the presentation layer.

In the last couple of years Javascript, which was available server
side back in the Netscape days (it was called LiveWire), is making
its comeback in the application server layer with a bunch of new
developments like OpenMocha, Phobos or Helma.

http://helma.org/
http://openmocha.org/
https://phobos.dev.java.net/

So, to sum it up: a future web development framework would include
an application server that exclusively served webservice requests
preferably in a REST way and in JSON format, explicitly barring any
output of presentation/HTML code. Although it could work in any
language, Javascript would probably be the best option given current
trends.

— MV