Monday, January 12, 2009

Better Java Web Frameworks

I have been doing web application framework development for a long time. In my first experience, we developed a “Web Application Framework“, to ease development so that even business user could make development. As the years passed, I never see any business user entered self development because of the fact that this job belongs to programmers. Today some 4GL or DSL tools are still on the search of the same promise. Before writing our own framework, we had used WebObjects development tools, to make Java web development. It was very good platform that front-end GUI development could be done from a GUI editor with a component model. Every web element can be used as a component and it had events like “clicked”, and click handler Java code can be added with double-click in GUI editor. One disadvantage was portability that you were bound to this platform and its Application Server. This model was similar with Visual Studio ASP.NET development environment that was present years ago from .Net emergence. After years later, JSF tries same model.

Web Application Frameworks meet the web application requirements. It is hard to define its border, but it should at least support presentation layer. It may expand to “Business Logic” layer or data access layer. In Java, we have following technologies for web development; JSP, Servlet, JSF, EJB. There are many Java-based web frameworks; Struts, Spring(Spring MVC), GWT, WebWork, Tapestry, Apache Wicket etc.

Power of Java and richness of web technologies produced many web frameworks (We don’t even see many internal frameworks). It is getting harder and harder to find a compatible development environment. Even some of vendors are pushing to scripting languages for “Ease of Development”(One another interesting move is “Cloud Computing”). I don’t favor scripting languages for enterprise web application development for “Ease of Development”. On the other hand, “Ease of Development” is a very important topic for programmers (I mean this includes both “Ease of Testing” and ”Ease of Deployment”). “Ease of Development” is closely related with productivity. As development environment complexity increases, development becomes harder thus productivity decreases. Today, we witness low-productivity in many software projects. Low-productivity results low-quality and delay in projects. We need better, simpler and yet powerful web frameworks that truly understand web architecture and its requirements. It is very important to make value proposition of framework before accepting.

Choosing A Java Web Framework: A Comparison

Choosing a JVM Web Framework

The API Field of Dreams – Too Much Stuff! It’s Time to Reduce and Simplify APIs!

Rethinking JSF - The Real Problem

Criticisms of Spring, Struts, PHP, and Rails

Here are required features of a web framework according to our enterprise application development experience:

1- Includes all core application layers (MVC):
Web framework should include data access, business logic, controller and presentation layers internally. As frameworks turn out to be an integration hub, it looses value. Every integration among the core layers introduces new complexity, new glue code, new dependency, and conflicting of intersecting features. If data access layer (Model) uses another framework, presentation layer (View) uses another framework, integrating these frameworks adds a very big challenge even if frameworks support each other. Replacing any framework causes many new problems later. For example, JPA is developed for data access independence but at this time you are limited only the features of JPA. IDE is a major development tool, but at this time we need an “Integrated Development Frameworks” environment within IDE. (Similar with ERPs that brought together enterprise applications under the same umbrella)

2- Avoids heavy-componentization:
In web architecture, desktop-like componentization is heavy and inflexible. Components in desktop applications were very successful. They utilized reusability and used in IDEs. In web applications, component model doesn’t work at the same form. Efforts to convert HTML (+JavaScript) into component model will not be successful as desired. This is because HTML is dynamic (DHTML), works on client and declarative (Declarative Programming). With heavy-components, we loose declarative programming to some degree. We loose “Web Graphics Designer” ability to edit web pages because of moving from design-time to run-time and moving structure information from HTML to programs (With losing HTML Editors functions). Web editor’s favorite structure place is CSS files so what about CSS componentization? Another problem is architectural. Web GUI has 2 runtimes; server and client (Browser). At previous years, web frameworks supported only server-side-only functionality. Then today we see client-side-only approach. I think best solution is balanced mixture of both client-side (JS) and server-side code with component templates (not hard components but light partial HTML+JSP+Servlet codes). I’ll not detail further, there are already many discussions about “Component-based” versus “Action-based” frameworks on the web.

3- No new tag markup or page template:
Some web framework requires learning a new markup with no added-value. Your form inputs turn out to be strange tags. Finally, developers don’t understand HTML, JavaScript, CSS because no time left for this learning. Who will fix GUI errors? Frameworks should bring minimum or no new tags (instead we may prefer attributes). HTML tags with simple JSP expressions are enough (KISS). Isolating developers from HTML and JavaScript is not possible.

4- No XML usage:
Heavy XML usage for configurations makes programs hard to develop, hard to understand, hard to test. One example is “Page Flow” information in XML files. Another example is bean configuration. Yes, pulling this information makes it flexible but who needs it? How many times your page flow changed? How many times did we utilize flexible bean configuration? What about source code readability? I don’t like “Dependency” so “Dependency Injection”. I think dependency is not free that you have to manage its subtleties. Here is my anti-pattern “Dependency Rejection”. XML can be used in other useful places like AJAX messages or data import-export.

5- Has its own web GUI page elements:
Rich web elements (say light components) are generally found only in JS or AJAX libraries. Web frameworks should provide rich elements like; Calendar, Dialog, Menu, Popup, Progress Bar, List, Grid, Tab (With sub-levels), Master-Detail Windows, Child Windows, Record Navigator etc. Developers can easily extend these elements. We are still turning around simple features like table sorting, filtering etc. We should step ahead. There is still no desktop-like web grid components to use (I see only in JS libraries) that I mentioned in my previous blog post.

6- Code generation:
Code Generation makes “Rapid Development” possible. Every part of software should be generated (Generative Programming); CRUD data access classes, business code, controller code, and view pages. Code generation takes development one step ahead of “Drag and Drop” WYSIWYG editors. If web framework facilitates code generation, developers could jump to customization details of application instead of building everything from scratch (MDA).

7- Has its own GUI JavaScript library:
Another bleeding integration point is JavaScript libraries. JavaScript libraries are not fully-integratable with web frameworks. They try to solve the problem in client side. What we need is close cooperation with client-side and server-side. Most of web frameworks unfortunately have no or little JavaScript in their presentation layer.

8- AJAX support (Asynchronous Communication):
AJAX eliminates bothering page-refreshes. Web frameworks should properly blend AJAX functionality into their code architecture. AJAX requires server-side coding. As we make client runtime powerful with AJAX, GUI state management code is duplicated. For example, if we update and fill a combo-box with AJAX call then server-side bean that is bound to this element is not aware of this state change. We have to change server-side state as well. AJAX functionality should be implemented without code duplication (Another interesting trend is AJAX MVC).

9- Portable among application or database servers:
Application and database portability is not easy. In Application Server side, class loader policies change, session management changes, deployment model changes etc. In DBMS side, join clauses change, paging, and sequence generating changes. Web frameworks should provide portable packages for different platforms. On the other hand, some web frameworks have their IDE and Application Server (believe me even DBMS). I think we must leave this job to the famous bright products (IDEs and Application Servers in the market).

10- Input validation:
Data input validation is a very important feature. If validation doesn’t occur in application, database error occurs. Database errors are not user-friendly. Some validation errors may not be related to database. Programmers need automatic validation according to database object metadata. Custom validations should be added if needed.

11- Bug-free:
Because of bugs in frameworks, all average developers become framework expert spending valuable time to figure out the problem. “Focusing business problems” is lost. I read many open source framework hacks and workarounds in many blogs which is not the task of developer.

12- Handles exceptions user-friendly:
If error or exception occurs, user-friendly messages should be returned. Application programmer has some responsibility for this but web frameworks may ease this task.

13- Eliminates double-click, double-submission problems:
Double-click may cause double-submission. Double-submission may cause unexpected errors in application (2 threads tries to do same thing). Web frameworks can eliminate this problem even in client-side without going to server.

14- Authentication and authorization support:
User login (authentication) is still developed by programmers without knowledge of SQL-Injection attacks. Web application authorization is still missing. Who will be granted for CRUD on which application etc.?(User roles, permissions) I am sure that in every enterprise web application, application authentication and authorization is re-invented.

15- Security controls for web attacks:
Web frameworks should prevent web security attacks like; Cross-Site Scripting (XSS), SQL Injection, URL Manipulation, HTTP Injection, Session Hijacking etc. Web client data is un-trusted and open to tampering so this is why we can’t quit totally server-side validation for the sake of client-side validation.

16- Reporting integration:
Reporting integration is important. We need reporting products/frameworks integration. Would you use your data access objects in your reports? Would your reporting engine use the same JVM runtime?(Embedded Reporting)

17- Messaging and workflow integration:
Web frameworks may support easy integration with messaging (JMS) and workflow products. Workflow is one of major element of BPM (Business Process Management). In some middleware stacks, this is included (i.e. JBoss Seam jBPM). Web application frameworks may support business events and workflow activities. These events can also be used to feed messaging backbone (ESB).

18- Application to application integration (i.e. Web Services):
In Java, there is external system (EIS, legacy) integration API, which is JCA, but inter-application communication within same JVM is not standardized. Let’s say we have 2 applications and one should use some call other application code. There is no standard for this. Basic solution is just adding other application’s path into its class-path and then using other application objects. We developed an Adapter API for standardization of this. In one-application environment, this is not a problem but if many applications are required to communicate, it gets more important. You can even convert your APIs into web services when necessary (integration with remote or non-Java systems). Web frameworks may provide tools for web services code generation, deployment and monitoring.

19- Admin application for run-time process and user session monitoring:
This is very important in point of user and system management view. What are my users executing at the moment? Which applications take longer to finish? Which users are on-site? Which pages are they surfing? In each session, which objects are they created? What are the URLs that a user requested? Which SQL statement did a user execute?

20- System resource management:
If your application runs big queries that require a lot of system resource (CPU, RAM, DISK I/O), we are faced the reality that resources are limited. If applications don’t restrict user processes, then system will consume its all resources and will not respond to even small processes. For the sake of system availability some user may be rejected by system. Web framework may have such limitation API’s.

21- Cluster support:
When server load is high and performance is a major concern, load-balancing is required. Application server clustering will not suffice, web frameworks must support cluster architecture. One simple example is framework’s id generators. They will collide in clustered Application Server environment.

22- Multi-database, multi-company, multi-window, multi-session support:
Application user may need to work on multiple database instances. One user may have to work with multiple companies. User may want to use multiple GUI windows. Web framework should handle or prevent state corruption among windows. User may need to work on the system with many sessions.

23- Internationalization:
If there are global users, then i18n support is important. One key aspect here is Application Server and DBMS should also support your localization.

24- SSL support:
If web application is wanted to be secure in insecure networks, SSL-support is important. SSL deployment in HTTP Server would not be enough. Even if SSL is not used, frameworks must encrypt sensitive data between client and server, like user passwords.

25- Document attachment:
In every enterprise application, document attachment is important. Users may want images, Excel documents attached to their application records. Every programmer first search for an upload utility then tries to understand server document folders. Instead, built-in functionality saves valuable time.

26- Mobile device support (i.e. Internet Explorer Mobile):
If we want to plan mobile access to our applications, how can we do this with web technologies? Many mobile devices have built-in web browsers and we may run our applications in these browsers. Web framework mobile support would be very beneficial at such cases. Otherwise, you should explore mobile web browser limitations by yourself.

27- Portal features:
Partial web components should be supported to use in Portals or external sites. In portal terminology, its name is portlet. There are many synonyms; Widget, Mashup etc.

28- Scheduling:
Application task may be batched and scheduled. After task completion, users may see results.

29- Keyboard hot-keys:
Users, especially old TUI (Text UI) users want keyboard hot-keys. Buttons, command icons should be bound to hot-keys. Web frameworks elements can support this instead of developing in every application.

30- Alerts between users:
Users may want to send messages to each other or system admin may want to send messages to users like notifying a shutdown or an application restart. This feature will be very handy.

Since this list is long enough, I had to skip these features (plus non-functional features); email support, back button, page navigation, bookmarkability, post-get support, formatters/converters, page skins, context-sensitive helps, URL manipulation, caching, logging etc.

This feature list is application-centric. Web-site-centric feature list may have different items. In web development, these 2 camps (web-based application developers and web-site developers) are joined and have some conflicting requirements. Scripting languages (PHP, Ruby or Groovy) and RIA platforms (Flex, Silverlight or JavaFX) may be much more appropriate for web-site developers. This is a controversial issue and differentiates framework architecture. In this aspect, we say that some web frameworks are much more appropriate for web-site development and don’t fit into enterprise application development.

Another argument is “Web architecture is not appropriate for enterprise application development”. I think we overcome the barriers of web architecture with many bright standard technologies thus making it a good application platform; Powerful Browsers, JavaScript, CSS, HTML(DHTML, XHTML), XML technologies, Web Services and finally AJAX meet the application platform requirements. Let’s make Web 3.0 possible.

11 comments:

xorn said...

And...
Have you found anything that comes close to resembling this mythical framework?

Jose Noheda said...

IWebmvc2 aims to achieve precisely that ;-)

Dan Howard said...

Have a look at Jolene. It's not a web framework - just a view which can be used to replace JSP/Velocity. It's a true separation of concerns using only real valid html.

http://jolene.sourceforge.net

Nacho said...

Seam is quite good, and comes quite close to your wish list.

Ibrahim Levent said...

To xorn:
Software stacks(platforms) of some big vendors may have these features like JBoss Seam, Oracle Fusion or SAP Netweaver. One important missing feature for them is portability (It is the natural result of utilizing platform features for high-integration).

Dean said...

Point 1 - I couldn't disagree more. I don't want my web framework to govern my data access layer, I want it to govern my view, and that's it.

Cédrik said...

19- Admin application for run-time process and user session monitoring:
This is an area where MessAdmin excels.
Being light-weight and very robust, it is an ideal solution for monitoring production servers.
The only part not covered (for now) is SQL monitoring. This feature is on the list thou.

You seem to have quite a few ideas on the subject. I would be very interested in your feedback, although I am confident you will like what MessAdmin offers. :-)

Cédrik said...

I forgot to add, for #30- Alerts between users: you've got your base covered here by MessAdmin (sysadmin to users only). This was a functionality that was in version 1!

Doerr said...

Dean is right "I don't want my web framework to govern my data access layer" - data modeling has matured over a long time. Based on Codd's concepts, the entity-relationship method makes IMHO most sense. Powerful tools are available that can also bridge the gap between programmers and users.

Frameworks who take over the model layer - most do - regularly fall back wide behind this level.
So, I'm very cautious when I read "full MVC" - it mostly means "20 years back" with regard to data modeling.

cameo said...

The framework is called AribaWeb.

Ibrahim Levent said...

Yes I know this is not a common requirement, I removed "Barcode Support" item from list.
I agree with Mr. Howard Lewis Ship about this who responded me from his blog as "Tapestry's Response".

"Barcode is not a general requirement but in ERP applications it is very useful (AI/DC Automatic Identification/Data Capture). Barcode printing, barcode reading and matching may be provided by your web framework.(What about RFID?) Would your reporting product support your application barcode?"