Here is the big picture of less4j applications:

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.