Better Java Web Frameworks was posted on JavaLobby and as it is to do with Web Frameworks I have decided to make the case for AltioLive.

I have structured the response to include the text from the original posting followed by a comment relating to AltioLive’s support for the functionality.

Includes all core application layers (MVC)

“A web framework should include data access, business logic, controller and presentation layers internally. As frameworks turn out to be an integration hub, it loses value. Every integration among the core layers introduces new complexity, new glue code, new dependency, and conflict 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)”

The AltioLive integration layer was discussed in December last year in the article AltioLive Presentation Server features. The reasons for AltioLive having an IDE inside the web browser are described in the blog item “Why does AltioLive have its own IDE?“. Logic associated with user interface interaction is handled within the client side application, while business logic is expected to be handled on the server via web services, Java code etc.

Avoids heavy-componentization:

“In web architecture, desktop-like componentization is heavy and inflexible. Components in desktop applications were very successful. They utilized reusability and could be used in IDEs. In web applications, the component model doesn’t work at the same form. Efforts to convert HTML (+JavaScript) into component model will not be as successful. This is because HTML is dynamic (DHTML), works on client and is declarative (Declarative Programming).
With heavy-components, we lose declarative programming to some degree. We lose “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 (while losing HTML Editor functionality). A web editor’s favorite structure format is CSS files so what about CSS componentization?
Another problem is architectural. A web GUI has 2 runtimes; server and client (Browser). In previous years, web frameworks supported only server-side functionality. 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 will discuss this further, there are already many discussions about “Component-based” versus “Action-based” frameworks on the web.”

AltioLive 5.2 has introduced a mechanism by which business components can be created from low level widgets to create composite applications this is discussed in Altio support for composite applications. I believe the ability to create components by aggregating widgets is a must for business solutions where re-use is important. While each technology may use its own approach to achieving a component I do not think it is something all frameworks should support.

No new tag markup or page template:

Some web frameworks require 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 there is no time left for this learning. Who will fix GUI errors? Frameworks should bring a 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.”

AltioLive stands apart here, it is very much a declarative environment. In fact the user interface is designed using an IDE you insert logic using actions and where necessary call out to JavaScript. The hardest issue here is if AltioLive should be called a development tool or a power user tool, at the moment it sits in between. In the future AltioLive will focus on appealing to both developers and users by providing scripting languages for developers and wizards for power users.

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 does your page flow really change? How many times did we utilize flexible bean configuration? What about source code readability? I don’t like “Dependency” or  “Dependency Injection”. I think dependency is not free as 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.”

If you agree this statement then AltioLive will not be for you. AltioLive is all about using XML to declare the way the user interface looks and behaves, although the designer provided with AltioLive means that you do not have to be exposed to the XML source files. I am also a strong believer in “Dependency Injection”, “Inversion of Control”. Many AltioLive solutions have a server side layer that incorporates SpringFramework for handling business logic.

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 this only in JS libraries) that I mentioned in my previous blog post.”

As far as I can tell AltioLive supports all of the functionality discussed. What I would like to see is more third party developers writing new controls for the AltioLive framework, especially open source controls.

Code generation:

“Code Generation makes “Rapid Development” possible. Every piece 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 a web framework facilitates code generation, developers could jump to customization details of application instead of building everything from scratch (MDA).”

AltioLive takes the user interface declarations and executes them at runtime, there is no code generation before execution of the application. All logic is handled through declarative action statements.

strong>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 on the client side. What we need is close cooperation with client-side and server-side. Unfortunately, most of the web frameworks have little or no JavaScript in their presentation layer.”

Very little JavaScript is used in AltioLive, if you use Java6u12 on the server then most scripting languages can be executed through the AltoLive presentation server.

AJAX support (Asynchronous Communication):

“AJAX eliminates 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).”

AltioLive supports push data and asynchronous processing of data as described in AltioLive - Pushing data to the client. The concept of binding client and server data together is a good idea, but I have typically found that users want control on when the data change takes place. The AltioLive alternative to a user action committing data is to add an AltioLive action whenever the data changes.

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 own IDE and Application Server (believe me even DBMS). I think we must leave this job to the famous products (IDEs and Application Servers in the market).”

AltioLive can be used on all major Application servers and makes use of JDBC for database connections. Yes, AltioLive has a very simple database for prototyping which will probably be replaced in the future with an alternative such as MySql. AltioLive also has a client side in memory database to provide efficient access when large volumes of data are being used in the client. The AltioLive IDE was around before AJAX had a name and Eclipse wasn’t rich enough to allow the creation of UI widgets, also some clients favour a Web based IDE for security reasons.

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. “

AltioLive Formatting rules I feel covers this. AltioLive allows fields to be declared as required and the data type to be defined, as well as specifying validation rules.

Bug-free

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

Well I’d really like to say all software is bug free. The wider discussion should be around proprietary verses open source.

Handles exceptions in a user-friendly way:

“If error or exception occurs, user-friendly messages should be returned. Application programmers have some responsibility for this but web frameworks may ease this task.”

I agree, and all products including AltioLive can improve in this area, the question I always ask myself is how much information do you log and how much do you give to the end user.

Eliminates double-click, double-submission problems:

“Double-click may cause double-submission. Double-submission may cause unexpected errors in application (2 threads trying to do same thing). Web frameworks can eliminate this problem even in client-side without going to server.”

In AltioLive this can be overcome in many ways- displaying a processing dialogue that disappears when the transaction is complete, or by clicking the button and closing the open window or screen, or disabling the button while the process is executing are amongst some of the options.

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 CRUD access on which application etc.?(User roles, permissions) I am sure that in every enterprise web application, application authentication and authorization is re-invented.”

Couldn’t agree more, but would one size fit all and how complex, how simple would such a framework need to be. At the moment AltioLive doesn’t support this because it is normally engineered into the solution. Each organisation has its own preferred way of doing things.

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. “

AltioLive is an Applet, so all data has to come from the server that hosted the applet. AltioLive separates SQL into a server side configuration preventing modification to SQL statements. There are no URL form submissions in AltioLive and client server communication is encrypted. Data stored on the client is held in an in memory database so is not easily accessed unless through the AltioLive API. Also, there is no client side script that can be used to investigate how the system works. So while all of this cannot guarantee  100% security, I am not convinced any system can.

Reporting integration and barcode support:

“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? 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? “

I do know of one organisation using AltioLive that has created their own Barcode controls for use within AltioLive, but I have never comes across any further demand. Reporting is more interesting there is a  lot of interest in report functionality from existing and new AltioLive clients. To address this  AltioLive 5.3 will introduce report scheduling and creation.

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). “

AltioLive has very basic workflow but relies integration with other products to provide full workflow solutions. AltioLive integration with JMS is mentioned in SOA + RIA - The AltioLive Solution and AltioLive Presentation Server features.

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 two applications and one should use some call to the other’s 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.”

AltioLive does not directly solve this problem. That said maybe the AltioLive composite service requests mentioned in Altio support for composite applications goes some way to solving this problem.

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

“This is very important in the case 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?”

Not convinced this should be part of a framework, some nice ideas that should probably be seen in the AltioLive application administration screens. I do think many of the features belong deeper in the logic of the application. I wonder how many people would then be concerned with performance issues associated with large amounts of logging.

System resource management:

“If your application runs big queries that require a lot of system resources (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. The web framework may have such limitation API’s.”

I’m not convinced a web framework should be responsible for this, I would like to think clustering and load balancing solves the problem.  To some extent I can see the argument for the web framework preventing the problem. But, this leads to users and designers blaming the web front end when user tasks become sluggish or are prevented because of the inability of the back-end system to cope with user demand.

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 a cluster architecture. One simple example is framework’s id generators. They will collide in clustered Application Server environment.”

AltioLive has many possible configurations for clustering that ensures load balancing and fault tolerance as mentioned in AltioLive Presentation Server features.

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

“The application user may need to work on multiple database instances. One user may have to work with multiple companies. The user may want to use multiple GUI windows. Web framework should handle or prevent state corruption among windows. The user may need to work on the system with many sessions.”

I’m not sure what the issue being raised here is. AltioLive supports multiple databases, a created application can make use of any number of database sources, web services sources etc. “Multiple GUI” windows - if this means a Multi Document Application then AltioLive supports this.

Internationalization:

“If there are global users, then i18n support is important. One key aspect here is that the Application Server and DBMS should also support your localization.”

This is supported by AltoLive, the browser provides the locale and as long as the language files for the application are implemented on the server then captions for controls use the correct locale.

SSL support:

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

AltioLive provides encryption of passwords, but will rely upon the SSL of the HTTP Server for secure connections.

Document attachment:

“In every enterprise application, document attachment is important. Users may want images or 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.”

This sounds like a nice to have requirement, there are many solutions to this problem and I am not convinced a generic solution provided by a framework is going to meet all requirements.

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. “

There is no quick win to this. In my opinion there is no simple re-use of screens in a web browser that will work in a mobile device, especially when the application needs to provide a rich user interface. The user interaction for a mobile device is different to a desktop computer and applications need to be adapted as necessary.

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. “

Something to be revisited again in future versions of Altio. Portal support was available in early versions of Altio but we have found that this has never been high on client priorities.

Scheduling: 

“Application task may be batched and scheduled. After task completion, users may see results. “

Task scheduling will be supported as part of the AltioLive Report Writer (AltioLive 5.3), other bespoke solutions using quartz or offline processing have been achieved using bespoke server side solutions integrated with AltioLive.

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. “

Keyboard hot-keys are fully supported by AltioLive and are defined at design time.

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. “

Easily achieved in AltioLive by making use of data pools on the AltioLive  Presentation Server. AltioLive provides Application Server administrators with the ability to post messages to all or individual users.

AltioLive Product Summary

AltioLive is not a typical Web Framework like Tapestry, Struts or Wicket, it provides a higher level framework that enables the rapid implementation of rich web front ends. The AltioLive architecture consists of a server side component that enables integration data sources and a Java Swing front end.

It is the aim of Altio to allow power users to be able to build their own applications as quickly and easily as possible by reusing components created by the software development teams.

The core product is not open source but can be downloaded for free and used for production deployment with a restricted license.