jZeno

This section should provide some background about, and a high-level overview of jZeno as a full-stack web-development environment. It is organized in 3 major sections, that will describe :

1. The type of application jZeno is currently being used for.
2. The programming model used by jZeno, on all 3 application layers (Presentation, Business and Domain Model).
3. Important performance aspects of jZeno.

In this section we try to give you an impression on what kind of applications are being built with jZeno.

jZeno is currently being used for typical web-based enterprise applications. A typical application would consist of a complex web interface that allows users to interact with the application, some messaging interfaces to allow interaction by other systems, some direct RMI interfaces (SOAP or other), limited reporting (complex reporting is better handled by specialized tools such as Cognos, etc...). Typically these applications will also contain a fair amount of complex business rules/validations/etc.. that benefit from a fine-grained domain model. This domain model results in a fairly complex database with typically 100+ tables, some of which may contain millions of records.

Using jZeno is particularly beneficial if your user interfaces are going to be complex. Many parts of the interface may be specialized screens for different type of users using the system. Parts of information that need to be visualized on your interface are often similar throughout the different parts of the user interface. A large portion (say 70%) of such business applications is presentation layer code.

The main idea behind jZeno's programming model is that application developers creating the above class and scale of applications benefit greatly if they are allowed to use powerful abstraction techniques (OOP/Design Patterns/AOP/Generics/internal DSLs/...) on all layers of their application (including the presentation layer). We argue that current generation of web development frameworks are too much geared toward implementation details (Javascript/HTML/CSS/HTTP/etc...) and are mostly unfit to apply standard abstraction techniques (specifically templating languages often inhibit this).

We also believe many types of persistency layers commonly in use today are again too much geared towards handcoded SQL and stored procedures. jZeno tries to take away many of these details by using ORM.

Besides presenting you with a comprehensive high-level programming model jZeno insists on providing ways to selectively bypass the abstraction layers it adds. We fully recognize that there will be cases where you want more control on the low-level details, but we hope that we cover 95% of the common tasks effectively.

Early web application development techniques (simple dynamic web pages) were centered around the idea that you could basically take an HTML file, and process it before sending it to the client, hence the plethora of scriptlets/templating languages, etc... Nowadays we are trying to build full-blown enterprise applications in this same model. In essence we never departed from the early model. We believe a pure java code based approach is much better for these complex business applications.

The Presentation Layer

jZeno comes with a fairly large number of built-in components that can be composed to form new custom components, screens, dialogs, etc.. This composite structure allows for reuse of reoccuring parts of your presentation layer. Other abstraction techniques can be used like expressing variations on a common theme through traditional subclassing, other design patterns, AOP, generics, etc..

This layer can be bypassed by implementing custom rendering components, giving you full control over HTML/Javascript/etc...

The Business Layer

jZeno comes with a stack of built-in aspects that provide services to your business facades (transaction management, logging, etc..). Among other things it is capable of automatically synchronizing changes to domain model objects you make on the presentation layer, or the business layer, to the database transparently. In effect the perspective you have inside of the business layer is that you have domain model objects that are somehow automatically persisted. This reduces your learning curve for ORM significantly (You do not need to learn the details on how to use Hibernate's session correctly).

Obviously you still need a query mechanism to retrieve a subset of all persistent domain model objects quickly. jZeno applications use Hibernate's HQL language to do this.

No need to write hand-coded SQL for most of the application, although Hibernate's Native SQL Query mechanism allows you to bypass this if needed. Alternatively it is possible to obtain a pure JDBC connection inside of a business facade and execute hand-coded SQL, or call stored procedures, etc.. (If necessary).

The Domain Model

All persistent data in jZeno are represented as objects, which can again have rich behaviour and be used in any standard design pattern, or other abstraction technique.

One of the often used arguments against this kind of fine-grain modeling of business applications is that performance will not be sufficient. We are convinced that this is not inherently so, and have achieved very good performance on the applications we have built so far. This section will highlight some aspects of the performance optimisations we use and will hopefully convince you that at least the class of applications described above can be created succesfully in this fashion. jZeno uses (among others) these optimisations :

• Delta updates. As a web page/screen is loaded by the user's browser, changes to a page will not trigger a full page reload, but only updates the HTML that is modified on the page, greately reducing the cost of a roundtrip for things like opening an extra dialog, validating input on the server, displaying error messages, expanding a section of the screen, sorting a small table on the screen, etc...
• Support for asynchronous roundtrips. Server interaction can be processed in the background for selected events. This prevents the application from blocking until the current roundtrip is complete.
• GZIP Compression. Any full page loads (as well as the delta updates) are compressed on the network via GZIP compression. This reduces the average web response size by about an order of magnitude.
• Batch Fetching/Breadth-First Swizzling. As you retrieve domain model beans from the database the executed queries are optimized so that as few queries as possible are executed on the server.
• Domain Model Caching. Typically an application will effectively use a small portion of the total domain model. It makes good sense to keep a fair amount of these often used objects in memory, further reducing access to the database server.
• Fast Object Creation. Instead of creating components and other objects when a user issues a new web request, objects can be created on spare CPU cycles outside of the request thread (and/or on free CPUs on multi-CPU machines).
• Flyweight state management. Instead of storing the state of server-side components in memory for every individual user, state combinations that occur throughout your application are shared by all sessions. This greatly reduces the heap usage per additional user that logs on to the system. (see GoF design pattern 'flyweight')
• ...