Conclusion of the SOFEA series: Future of web-development/RIA


To summarize this series, I will shine the light on some of the more important points from the series.

I really believe, that at some point in the future, there will be an unified web-development environment (UWE) for the web which allow the developing of a whole, single application in one language which will then get broken up and compiled into the client and server parts by the compiler. So essentially the compiler decides where to draw the line between client and server – possibly with some help from the developer in the form of annotations, some description file or specific classes.

With this it is entirely possible that the program can be compiled into different representations, i.e. different languages for different deployments – for example a part for deployment on a server running struts and another one running ruby on rails, and client parts for a very thin – read restricted – mobile client as well as a very rich/powerful client. This naturally moves the break-up line between client and server which is why the compiler needs to be able to decide that at compile time.

What language the unified application is written in, does ultimately not matter since all languages that are Turing-complete can be crosscompiled. But since it is more complicated to compile from a non-VM language into a program that can be run in VM, it should be a VM language, even if it is one with strong typing like Java. The GWT is a very good step in this direction, and it shows that it is possible to write the client-side part in a different language (in this case Java, which is close enough to JS to make that easy) for easier development and debugging and then cross-compile it for running on the client.

I think that fusing GWT with a similar toolkit for the server-side, maybe based on struts or some other Java webserver and implementing a generator for the marshaling, can be an important first implementation of this unified web-development environment or toolkit. If somebody is interested in this, maybe it can be suggested as a project for the google summer of Code (SoC).



Seems to me like CS people like to invent new names for the same concept, doesn’t it? Don’t they all mean the same anyway – Service Oriented Architecture?

They do. The idea behind those terms is to decouple the business logic (BL) or the actual application code providing a service, from the front-end consuming that service. Basically, what webservices do. They provide a service and return the data in a standard format without adding any presentation information to it (i.e. HTML). That leaves the job of interpreting and rendering that data to the front-end application logic, which can very well be a piece of JS code running inside a browser.

This is really good, because it decouples the application (BL) logic – or Controller if you will – from the presentation logic, the View; meaning that you can develop them independent of each other – or change one of them without changing the other; as long as they both adhere to the contract laid out for the service, they work.

The downside of that approach is that most SOAs are inherently stateless because they assume that front-ends come by, request some kind of simple service and then go about their business – what theory nerds call ‘loose coupling’. Yahoo’s webservices are a good example – like the keyword extractor: Send a long text to it, and you get extracted keywords back, it’s as simple as that. This might be good for simple things, but as soon as services get more complex, require logging-in, or involve extensive BL, that becomes a drawback. Now there are only two options: Either forget the statelessness of the service or transfer that state w/ each request anew. The first breaks the model of SOA which is not good, whereas the second might end up transferring lots of data and – you guessed it – creating the same problem that HTML has all over again (crafting state onto a by definition stateless protocol).

But remember, SOA does not command to be stateless, it merely states that it is beneficial if the services are loosely-coupled. This can very well be achieved by breaking your BL into small, distinct services that might each preserve a small amount of state: an auth. service, a basket service, a pref. service etc. all communicating with each other. The downside again, is that this generates more traffic/latency between the services thus degrading overall performance. But – oh well – there is always a trade-off, right?

So, whats there to do? Well not much, either accept one of the two solutions, find a middle-way depending on your needs and environment or implement only simple services using SOA principles.

Series about SOUI/SOFEA


Hello everybody!

Since I became interested in GWT a while ago, after deciding to use it in my next project, I read a lot about the next trend in RIAs and had decided to write something about it before I even learned that its known to most people as SOUI or SOFEA. I am going to turn this into a small series – instead of just one entry.

While I read, I bookmarked everything and published it on delicious ( So before we start, I’d like everyone to browse through my links at their leisure and get up to speed on the current field, before we kick of the lecture w/ the first installment entitled “Ailments of current web development“. Pay special attention to the paper “Life above the service Tier”.

Reblog this post [with Zemanta]