I'm the father of ItsNat AJAX Java web framework, JNIEasy, LAMEOnJ, JEPLayer and JEPLDroid libraries (and very old stuff like XPDOM), supporter of the Single Page Interface (SPI) paradigm, writer of the SPI manifesto and currently Android native guy. Jose Maria has posted 28 posts at DZone. You can read more from them at their website. View Full User Profile

Better Java Web Frameworks: ItsNat

01.30.2009
| 12386 views |
  • submit to reddit

Ibrahim Levent has recently written an interesting article, here at JavaLobby, about how a (Java) web framework should be, based on his own experience.

According his list of "requirements", this article reviews how ItsNat web framework fits or not fit in his ideal framework. In spite of I'm reproducing the headlines of the original article, I recommend reading it to fully understand what motivations are behind.

The style is as dialog, "you" is Ibrahim but can be replaced by yourself :)

This article wants to be helpful to the work inited by James Sugrue in a previous post to classify the web framework ecosystem.

No more introduction to the Ibrahim Levent's interview to ItsNat, in bold is the requirement of Ibrahim of an ideal Java web framework that...

1.Includes all core application layers (MVC)

I don't fully understand this requirement. Are you arguing any web framework must be integrated "out of the box" with a concrete database layer? I don't think so, more coupling less freedom of choice, and in the persistence world there are many options: pure JDBC, iBatis, pure JPA, Hibernate, JDO, legacy databases... Furthermore, coupling may impose not only how data is retrieved but also when is retrieved, for instance if your data is mostly read-only, it could be loaded when the user logs into the web.

In page based applications usually the target page is loaded with fresh data, how is this applied to AJAX and partial updating? 

In the case of ItsNat it is a pure Java web framework and agnostic about persistence.

2. Avoids heavy-componentization: 

I agree with you, the web environment is different to desktop, building components in desktop is possible but very complex, usually desktop applications have the same look and feel and components because the default components are used.

In web there is a tradition of "hand made" "components", HTML and CSS are relatively easy technologies this is because almost all web sites and applications are different. Fine control of behavior and look and feel in web are usually very strong requirements because these days any web site is a web application. 

In web HTML + CSS + JavaScript = DHTML, any "component" is possible (of course with many limitations), in desktop is possible too but not practical, almost no one has customized (or reinvented) the table component of Swing, in web there are miriads of different tables.

In ItsNat the templates are pure HTML and view logic is coded in Java using Java W3C DOM APIs. This gives you absolute freedom, you are not tied to closed components.

This freedom allows the framework to be integrated with client (JavaScript) libraries, a page zone controlled by the client may be a zone not controlled by the server and ItsNat provides a communication bridge with the server using JavaScript APIs and AJAX, and as the return of any AJAX event is JavaScript, the server can send custom JavaScript code to the client to control the client library.

3. No new tag markup or page template:

ItsNat templates are pure HTML, no specific tags, no expression languages, no Java bindings. They are not necessary because the page is reflected as a Java W3C DOM tree in the server. Furthermore, you can invent your own custom tags and replace them with standard HTML.

In the core level of ItsNat learning curve is plain: a very small subset of ItsNat APIs and Java W3C DOM APIs (the same API as in JavaScript) are enough, in some way ItsNat is DHTML in the server.

4. No XML usage:

 In ItsNat there is no XML files. I'm not a believer of declarative programming, configuration is made with APIs, this gives you freedom to reuse and read from file (using the format you like more) only the things really going to change. 

  You must define an entry servlet (a simple call delegates to ItsNat the processing of requests), this gives you absolute control of the bootstrap of your application, not impossed by declarative programming in XML or in form of annotations. 

 There is no "navigation in XML" because ItsNat promotes "One Single Web Page" (or Single Page Interface) programming, that is to say, no navigation, no reload, desktop style using AJAX received as events (converted to Java W3C DOM Events) in server to update the page partially or fully.

 Dependency injection is used as classic listeners, for instance event listeners use the standard Java DOM interface EventListener and are registered using a very similar API to W3C DOM (addEventListener).

5. Has its own web GUI page elements:

In ItsNat any server DOM element or DOM subtree (for instance a <p> tag enclosing a text node) is a component because it fulfills the common definition of (web) component: an item with a view (a <p> tag is a square box enclosing the text), a data model (the text node contains the data as a string) and can receive events (any DOM element may receive events, in the case of <p> can receive mouse events). In theory ItsNat doesn't need "components". 

In spite of this ItsNat has some typical components like lists, tables and trees, modal "dialogs" with some predefined behavior when events are received... this component list will be longer in the future. As said before ItsNat does not promote closed components, components in ItsNat do not have views, the view is defined as pure HTML code used as pattern and is "attached" to the component in Java (this is similar to Wicket approach). As the view is defined and controlled by the developer it can be highly customized using Java W3C APIs, the component is used to bind the view layout with a data model and a selection model (usually reusing Swing data and selection models) and client events.

For instance, this example developed with ItsNat, reuses CSS styles and HTML layout generated by another Ext-JS application (no JavaScript code of Ext-JS is used). This example shows how almost any HTML layout and behavior can be "reused" and bound to components in ItsNat.

 

The tabs are managed by a "free" combo box component and tables in "Cars" and "TV Series" are managed by a "free" table component.

Note: this example is not complete and is based on a v0.6 preview version of ItsNat to be released soon.

6. Code generation:

If generated code can be re-generated again with no user defined code destroyed (is fully separated of user code or supports some kind of roundtrip) is a good thing, otherwise is a very dangerous approach and just can be used to show to your mom "look ma a web application done with two clicks". This protototype is usually hard to bring to the desired final solution (and we know the final solution will be very different).

In ItsNat there is no "public" generation of code, of course JavaScript code is generated behind the scenes. 

7. Has its own GUI JavaScript library:

ItsNat is server centric, the style of programming is similar to JavaScript programming in client because the API is basically the same, DOM, in server is W3C DOM (using Xerces) because the framework takes care of the differences between browsers (including workarounds to fix stupid bugs in some browsers).

There is some JavaScript files included in the client but their use is internal and a very small subset is public and documented to be used by developers, for instance to fire and dispatch "user defined events" to the server from client JavaScript transported with AJAX. 

As said before with some care nothing prevents Dojo, JQuery etc be used alongside ItsNat, user defined events or simulation of GUI events can be used to communicate with the server and server can manage these libraries returning custom JS code generated by the developer in the server.

8. AJAX support (Asynchronous Communication):

In ItsNat AJAX is a basic piece, is not an add-on, because GUI events are sent to the server as Java W3C DOM Events, if a concrete DOM element is clicked a mouse click is received in server and dispatched to the Java based EventListener registered to listen this element in the server. Only events being listened in server (some listener was registered in server) are sent to the server.

ItsNat approach is "The Browser Is The Server", the browser state is managed in the server, so the browser is a sophisticated terminal of the server, in theory there is duplication but client synchronization with server is automatic, if any server DOM subtree is changed the client is updated accordingly. In summary, the developer only cares about the state of the server, there is no specific work or synchronization to transport server to client data and vice versa, no need of bridges transporting JSON or  XML data.

By using form components provided by ItsNat, client to server synchronization is automatic too. For instance, if the client selects an option of a select automatically the option in server is updated with a new "selected" attribute (Swing data and selection models can be used too to keep track of user actions). The same is applied with input text elements, the "value" attribute in server reflects the current value in client and if this attribute is changed in server the "value" property in client is automatically changed (this server to client communication doesn't need a component is the basic behavior of ItsNat).

By this manner ItsNat strongly promotes web applications in a single page with no reload. To help this objective, ItsNat defines pure HTML fragments, HTML fragments are pure HTML files used as templates to be included into the "server page" in any time because only the markup inside <body> or <head> is used, this way we can partially or fully update the page with no reload.

9. Portable among application or database servers:

ItsNat is database agnostic and can run in virtually any servlet container because is compiled with Java 1.4.

10. Input validation:

Normal Java code can be used to validate user provided data. Anyway input formatted components (inpired on JFormattedTextField of Swing) offers user defined validation support and automatic restoring of the previous (valid) value in the client.

11. Bug-free:

No software can claim is bug-free, no one. In ItsNat code quality is more important than features, for instance the upcoming v0.6 doesn't provide many new features but internal code has been highly refactored to be ready for future features like "full remote control".

Furthermore ItsNat transparently fixes many stupid DHTML bugs of supported browsers.

12. Handles exceptions in a user-friendly way:

In ItsNat there is no checked exceptions, this frees the developer of unnecessary try/catch. By using global event listeners and event listener chains (feature included in v0.6) the developer can catch almost any exception thrown by the framework of by developer code in different listeners.

13. Eliminates double-click, double-submission problems:

This is not a problem in ItsNat and single web page applications, in this kind of application there is no form elements.

For instance if you click a button and the listener in server processing this click removes this button and related listeners (in server and client), when the second click arrives to the server the target button does not exist in server (exactly there is no listener for this event) and this click is ignored. Note: in ItsNat the server only allows processing one event simultaneously per document/page (any other pending event-request thread will wait until the previous one finishes).

Furthermore ItsNat has a mode called ASYNC_HOLD allowing synchronous events using asynchronous AJAX, in this mode an event is not send to the server until the current event being processed by the server returns (is queued in client). When the first event returns the button will be removed, then the second event will be sent to the server but the target element will be unknown (only elements bound to the page document can receive events and register listeners)... again the server will ignore this event (in fact it could be ignored in client too).

14. Authentication and authorization support:

ItsNat is a generic web tool and doesn't provide this kind of predefined behavior.

15. Security controls for web attacks: 

ItsNat doesn't prevent SQL inject attacks because is database agnostic, SQL inject attacks can be avoided using PreparedStatement any decent ORM supports this. 

One advantage of a server-centic solution is security, in ItsNat the application state is in the server, including the view state and no business code is in the client this highly reduce any attempt of tampering.

Client to server communication is in the form of DOM events these events transport user data as strings and information about what element was clicked etc. As said before if the element clicked is not in the server and/or there is no listener associated to this element, the server silently ignores this event. There is no way to modify inadvertently the server state with an string because executable code is Java (compiled) and the view state is in Java too as a tree DOM (powerful methods like ItsNatDocument.toDOM(String) should be used with care, DOM API is securer).

Some security checks are built-in in the DOM technology, for instance if a string submitted by a malicious user is going to be published as a text node in the DOM tree, if this string contains a <script> tag trying to inject some JavaScript to other users, this tag is automatically escaped as text (&lt;script&gt;) by the serializer of Xerces or Xalan (both are used in ItsNat).

16. Reporting integration and barcode support:

There are other interesting tools for this task. Anyway ItsNat supports pure SVG pages including AJAX events and HTML with SVG embedded and components can be attached to SVG markup ("free" versions); SVG is great to build charts and ItsNat can help to surpass the typical image-based reporting.

17. Messaging and workflow integration:

I'm not sure is a good idea and most of people don't need these technologies. "Can be integrated" is different to "already included".

I like very much the phrase of the venerable B. Stroustrup

"Independent concepts should be independently represented and should be combined only when needed. Otherwise unrelated concepts are bundled together or unnecessary dependencies are created"

18. Application to application integration in the same JVM (i.e. Web Services):

Nothing to say about this because is out of scope of web technology.

19. Admin application for run-time process and user session monitoring:

In ItsNat this point is very important, ItsNat provides APIs to traverse user sessions and obtain the currently open pages in server (ItsNatDocument objects). This way a user can monitor or modify (from server) the page of another user.

This feature alongside the "The Server Is The Browser" approach of ItsNat are used to provide an amazing feature: user page monitoring. Any authorized user can monitor what is other user doing in his browser (only the page monitored), the page of the monitor is an exact copy of the monitored page and automatically changes when the source page changes using AJAX timers or Comet.

In a short future, full remote control will be ready, two or more users will interact with the "same shared page" (possible uses are open to your imagination, for instance helpdesk). This feature is already present as draft in v0.6 but disabled (if anyone is interested in how to enable this feature contact with me).

20. System resource management:

ItsNat has some support of resource control. For instance, you can limit how many pages are open, when a new page is open and the limit is surpassed the lesser active page is invalidated and removed from server.

Another resource saver is DOM caching, you can mark what parts of the web page are dynamic (in a server point of view), static parts are cached as markup (plain text) and shared between users in server. 

21. Cluster support:

At the time of writting session replication is not supported, in fact, session is not used by developers in a typical ItsNat (one page) application. You can cluster ItsNat if requests of the same user are conducted to the same server; in no way there is a conflict between ids managed by ItsNat and session cookie provided by the server container, furthermore, user (client browser) identity in ItsNat is based on the session identity given by the servlet container.

22. Multi-database, multi-company, multi-window, multi-session support:

As said before in a typical single web page application, the session object is not used, because the object used to communicate the client page and the server is the server document (usually "document" is the same concept as "page"), this way the same user can open two windows/tabs with the same information and nothing is shared (if the session object is not used by the developer). When the user leaves a page the document (page) in server is lost too.

23. Internationalization:

As view logic is in Java you can use the i18 tools of Java.

24. SSL support (Even if SSL is not used, frameworks must encrypt sensitive data):

I'm not sure whether this is useful. My bank does not use any kind of encryption to show my account data (SSL seems enough).

25. Document attachment:

I must recognize an AJAX based file component is a pending TO-DO. File upload can be done using form submitting.

26. Mobile device support (i.e. Internet Explorer Mobile):

In this chapter ItsNat shines because mobile browsing is seriously supported in ItsNat. Current version (v0.5) supports many mobile browsers with AJAX support, the upcoming v0.6 even more. The Server Is The Browser approach is very useful in mobile devices because the processing power is delegated to the server, any client intensive approach will fail in mobile devices (because they are strongly limited in memory and speed).

This is the list (all of them support AJAX and one page applications):

 IE Mobile 6 of Windows Mobile 6 and 6.1, Opera Mini 4+, Opera Mobile 8.6+ (including Opera Mobile 9.5 beta), Minimo 0.2, NetFront 3.4+, iPhone/iTouch, S60WebKit, S40WebKit, BlackBerry Bold/Storm (JDE 4.6+), Android, Iris Browser, QtWebKit of Qt (Qt 4.4) and SkyFire 0.8.5.

Try with any of them the "Ext-JS like" example (v0.6 based).

 IE Mobile (WM 6) support is unmatched in spite of DHTML in this browser is almost impossible... yes is possible (see IE mobile specific examples). Opera Mini 4.x support is unmatched too including in place edition (since v0.6), Opera Mini 4.x virtually works in any mobile phone.

In ItsNat a strong requirement is any feature or compoenent should work in any supported browser, this requirement is almost fulfilled including poor and buggy browsers like IE Mobile of WM 6.

27. Portal features:

Pending feature. Someone says that portal technology is becoming irrelevant but I'm not sure about this affirmation.

28. Scheduling (application tasks may be batched and scheduled. After task completion, users may see results):

ItsNat supports AJAX timers (polling) and AJAX long polling, both Comet techniques can be used to update automatically the client page when something in the server occurs.

Another technique is using an asynchronous task, with this technique we can start a thread doing something long and when this task ends the client page is notified.

29. Keyboard hot-keys:

There is nothing about default hot-keys in ItsNat, nothing prevents of listening keyboard events, in fact, keyboard events are unified and received as FireFox key events in server (key events are not standarized by W3C, yes really).

30. Alerts between users:

As said before ItsNat provides APIs to traverse user sessions and obtain the currently open pages in server (ItsNatDocument objects). With a document object we can see and modify the server state and then the client will be updated in the next request.

Many other things are not in the table like bookmarking in AJAX, server-sent events, back button etc, these web problems hopefully will be attended in the next long article of Ibrahim :)

 

 

Published at DZone with permission of its author, Jose Maria Arranz.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Philip Andrew replied on Sat, 2009/01/31 - 4:07am

The first problem I see is that it doesn't look as good as some other ones.

So my customer wouldn't like it... - eye candy 

Jose Maria Arranz replied on Sat, 2009/01/31 - 5:38am

Don't worry, pick your favorite HTML layout and CSS, save it as an ItsNat HTML template and you are ready to do anything with it. This is what I did with the Ext-JS-like example, the Java code behind is almost HTML agnostic because ItsNat components are based in "patterns".

If you are looking for drag & drop-closed-intrusive-out of the box-good looking-nothing more to do components... ItsNat is not for you because is "look and feel agnostic". ItsNat promotes freedom and developer control.

Anyway It would be weird if the car selector or configurator of Ford and Citroen web sites looked the same :)

 

Dan Mendes replied on Sat, 2009/01/31 - 10:05pm

I don't want to come out as to critical, but isn't this totally against a RESTful philosophy and Search Engine Unfriendly?

Say that i wanted to point my client to his car order using a unique URI, how would i present the ItsNat application page to my client? perhaps i am missinterpeting the concept of SPI.

Jose Maria Arranz replied on Sun, 2009/02/01 - 3:21pm in response to: Dan Mendes

@danmendes: I don't want to come out as to critical

Criticism is ever welcomed if it is constructive and polite :)


@danmendes: but isn't this totally against a RESTful philosophy?

A RESTful approach is a particular case of the SOFEA approach, thin server and tick client.

In my opinion this is a return to the fat client where the application is in the client as JavaScript. This may be appropriated for internal applications and applications not data intensive and very rich visually (many GUI events), but most of web sites and applications of the world are data intensive, that is to say, data is in the server and data is queried again and again.


If you can deal with tons of JavaScript code, security concerns (most of the application is in the client) and client-server data bridges (XML, JSON etc) the client centric approach may be fine.


In a server centric solution (most of) the application is in the server and JavaScript code in the client is pushed as necessary from server. In ItsNat data and view management is in the server, this free the developer of client-server data bridges, and view management is done in Java with the goodness of Java (strongly typed language, OOP, reusing in jars, first class IDE support etc). And a server centric solution is the only feasible solution in mobile browsers because these devices cannot load very much JavaScript (and JavaScript is sloooow in these devices), in this case more power to the server implies more power to the device.


In my opinion a server centric solution may be visually rich too. There are two concepts about what is a “rich GUI” in web:


1)    The static HTML layout and CSS is impressive. This is not a problem for a server centric solution. In the case of ItsNat any “impressive” HTML+CSS layout can be reused and managed.


2)    DHTML effects are intensively used. A server centric solution can push JavaScript to the client to manage events with no data relationship. In ItsNat components do not have “visual effects” because most of behaviour is related with data management and the data source is... the server. User defined code could push some JavaScript to do cooler effects, this is possible because the layout is almost fully controlled by the developer and some methods like ScriptUtil.getNodeReference() are very useful.


Anyway as said in the article, a JavaScript framework could be used alongside ItsNat, user defined events provides a client to server bridge using JavaScript code and AJAX and the server could be almost stateless (I don't like very much this approach but it can work).


I think a REST service must be published to provide a public data query/management service, this service is view-agnostic and has nothing to do with the web approach used to build a web application on top a REST based architecture, because in a server centric framework you can call your REST services in Java instead of the typical ORM based web application (the database would be behind the REST wall). In the case of ItsNat the Java code would be very similar to the JavaScript based version because the style of the development is like in client (DOM APIs).


@danmendes: but isn't Search Engine Unfriendly?


Yes and no. One Single Web Page (or SPI) approach is relatively “new” in web and I must recognize is a paradigm shift and may have some problems with search engines, but this is not an unsolvable problem.
With some work we can make our OSWP application searchable, in some way you need to cheat to the search engine with hidden links or with AJAX/normal links with default behaviour disabled by JavaScript (but not disabled for the search engine).


To make an OSWP application searchable you must identify the “fundamental states” (or searchable states or bookmarkable states) of your application. Another requirement is that the fundamental state must be served as HTML, this is not a problem for ItsNat because the initial page is served as normal HTML (but this is a serious problem for frameworks which pages are built using JavaScript code like GWT). 


The Feature Showcase is an example of an OSWP searchable application. Click the "Explanation" tab and "Source Code" to understand what is behind. Some ideas can be applied to other frameworks.

This is another OSWP ItsNat application using AJAX/normal links with default behaviour disabled (these links are "Help" and Contact... both pages are traversed by Google and anyother search engine).


@danmendes: Say that i wanted to point my client to his car order using a unique URI, how would i present the ItsNat application page to my client? perhaps i am missinterpeting the concept of SPI.


ItsNat can be used for “classic” page based applications, the pure HTML templating solution including Java W3C APIs, HTML fragments, fragment caching between users etc may be appealing but page based navigation is not the focus of the framework.

As showed before, direct links can be used to achieve a “fundamental state” of the SPI based application (for instance the car order).

In my opinion page navigation is the worst inheritance of the amazing invent of Tim Berners-Lee, page navigation was invented to traverse references of scientific documents not for applications. Simulating events in page based applications is a laudable and impressive solution but in the same time an ENORMOUS HACK.

I hope the Web 3.0 will be (technical point of view):

1)    One Single Web Page based
2)    Real Time based (by using Comet flavours like AJAX polling and/or long polling)

 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.