On the right, the most common private resources usually accessible by SQL and LDAP through JDBC and JNDI API.

On the left, the public interfaces is HTTP as seen through the HttpServlet interfaces and beyond it, the stack of standards that can be applied to or generated from XML and JSON resources: HTML, CSS, XSLT and JavaScript.

In the middle stands the application controllers, the brokers of public access to private resources.

Specifications

This framework is simply specified as a strict application of HTTP, XML, JSON, SQL and LDAP, to develop J2EE servlets that control public access to private resources.

There are other protocols and java API to access entreprise network or computer application resources, but those are usually specific to each applications and out of scope of a library and framework.

In this architecture, the HTML, CSS, XSLT and JavaScript applications are decoupled from their controllers. Which means that any user interface specialisation (like localisation) or aggregation can be developed in parallel, independantly from their controllers, possibly for very different browser or even hardware plateform.

Implementation

All controllers developed with less4j must be highly available.

To meet entrerprise safety requirements under a profitable Service Level Agreement, public interfaces demand a scalable implementation that is resilient to a denial of service and supports a comprehensive audit.

Test Case

The test of less4j success (or failure) is its ability to scaffold less java on the server for more applications of XML and JSON in the browser.

Nine files, thirteen public classes and one interface, that’s all there will ever be in less4j.

Practical Synopsis

I’ve allready been asked less4j examples but I’m doing this library by the book, first thing first. Only when my API is documented will I consider a tutorial of some kind.

This does not mean that I won’t put examples it the Javadoc, just that I’ll wait to have sound interfaces and implementation before moving to the next level of abstraction. To the contrary, I will try my best to give simple and general examples of the applications, along with a brief discussion of the implementation and interfaces.

Each class will eventually come with a usefull synopsis.

Javadoc Everything

Well, everything public. Classes, methods or members, everything public must be documented systematically, that’s an all-time demand from application developers.

The private and protected interfaces of less4j are for the library developers only and better explained to those programmers by their implementation sources and interface names.

No Comments

I tried to refrain myself and not pollute the sources with comments others than javadoc, which is a virtuous constraint that forces relevance into the interface names, making the code easier to read and understand

Free At Last!

The comments left that were stripped from the javadoc are those about past evils of java, the evils of a proprietary specification and reference implementation. Now the JVM is GPL and java is (somehow) free.

The documentation of less4j is part of its sources and therefore GPL’d too.

http://svn.berlios.de/svnroot/repos/less4j/

The objective is to support a rapid development cycle for web 2.0 controllers of entreprise service oriented applications.

In Java.

Why?

A while ago, I needed a convenient API to write distributed J2EE servlets that authorize, control and audit access to an SQL database or an LDAP server from a JavaScript client.

To make those servlets as fast as possible, this API must leverage the stable stack of web standards between a J2EE container and a modern web browser:

HTTP, URL, HTML, XML, JSON, CSS, JavaScript

Not work against it or obscure it.

I won’t wait for RubyOnJ2EE, I’m tired of HttpServletSession woes, I can’t take another HellWorld tutorial in 26 steps, I want JSON validation now and performances do matter.

So, I decided to write my own.