I do believe the center of Java development is the programmer who is creating object-oriented Java code. But how do you achieve this when developing Web applications? In the Internet scenario the client and server sides are disconnected: the front end is shown to the user miles away from where the real code that's reacting to it is executed. Even worse, the visual code is different from the code that executes the logic. How much time does a Java Web application developer dedicate to tasks that differ from real application logic? Forty percent? Thirty percent? And what about maintenance?

ASK is a front-end application server that provides the necessary support for numerous requests. This is achieved with a server-side server's topology. Within this architecture it's possible to set up as many ASK servers as you need, indicating which applications every ASK server should support, and also which applications run in which servers. All the architecture is described in one XML file.

ASK is built on the premise that the application logic should be 100% Java, 100% object-oriented, and 0% HTTP/HTML. To achieve that goal, ASK implements a Java server-side graphical component model that melts the client and server sides. All the HTTP complexities, like session management and navigation, are internally managed by the ASK front-end application server, thus Web application development is actually visual Java components and events handlers development.

The most typical problems that I've seen in Web application projects have been those that are related to team management trying to fit the application aspect tasks (designers, stylists) with the application logic ones (Java developers). It's hard to mix these two worlds with an efficient methodology. Using ASK helps solve this problem. The development process is as follows: Java developers develop the application and spend 99% of their time making it work (Visual Logic, DDBB, EJBs), without worrying about color, font, etc. Once it's ready, and that means really working, the stylist team arrives to set the skin. Since responsibilities are clearly separated, communication between the teams is minimal, reducing the overall development and maintenance time.

Most Web applications need to be executed in a secure, scalable, performance-efficient, and, hopefully, low-cost environment. ASK was developed from scratch taking all that into consideration but adding another requirement: simplicity.

A recursive question I get asked is: "What happens if the server crashes?" The answer is: ASK is applications fault-tolerant. It offers an applications crash-and-recovery service that's plugged into those servers where needed. Also, it's not active for all the applications; you decide which type of application should use it independently.

Performance is an issue, and this has been checked from the start of the development, conditioning many low-level design decisions. An ASK server is a simple thing; it doesn't need a lot of resources or to execute complex or heavy processes to handle applications. It's lightweight - the ASK code is compressed to 300KB. The amount of time an ASK server spends executing a call to your application is almost the same amount of time it takes your code to execute. You may have performance problems if the number of concurrent requests increases, as in any other situation, but then the solution in ASK is simple: set up another ASK server (with a low-cost but powerful machine, if possible).

ASK is an open-source (lesser GPL) tool that proposes a new, simple, and powerful way to develop Web applications, where simplicity and openness are a must.

Resources