Jaxer completes the picture by enabling you to:
- Prepare the HTML DOM on the server before the page is served, using the same techniques and libraries you would use on the client;
- Validate your data with the same code on either the server and the client.
Jaxer directly addresses the difficulties of building rich web applications and sites by providing a unified development model. You use exactly the same well-understood technologies on the client and on the server, resulting in a simpler, more efficient development process that lets web developers focus on delivering value: an entire rich web application can be written in a single HTML document.
Jaxer and Web Servers
Jaxer is not a web server and requires a properly configured Apache instance or similar to function correctly. More apt comparisons are app servers/ frameworks like PHP, Ruby on Rails and WebLogic.
Jaxer’s architecture has two main components: a back end server which does the real work and a framework (API) which developers can code against and extend. Their are two server-side components, the Jaxer server and mod_jaxer, an Apache module which creates a communication bridge between the web server and the Jaxer server.
Jaxer communicates with mod_jaxer, which is plugged into Apache
The Tech Details
Jaxer implements established web standards with no proprietary markup or protocols. Applications and sites can now be built purely on Ajax technologies end to end, or Jaxer can be used for just the presentation layer (on both client and server) that connects to an existing business logic layer programmed in, say, Java or PHP.
Jaxer fits comfortably within most IT network configurations
- Apache packaging allows it to function as a complete web application/page server
- Fits into an existing web server farm
- Can be deployed as a proxy for maximal flexibility, for example, for post-processing an existing outbound HTML stream
Examples of Using Jaxer as a post–pocessor
- Intelligently instrument the outbound HTML stream for monitoring performance and user experience and behavior
- Enforce security and compliance requirements
- Add new capabilities that were not designed into the original application
The architecture of Jaxer is such that you can scale horizontally quite easily. Jaxer is multi-processed with a manager that controls all the processes, similar to how Apache manages multiple httpd processes, and this allows you to configure Jaxer to best use the resources available on a single computer. As your application’s workload increases you can set up multiple Jaxer server machines to share the load. Each process is single threaded.
Whether your multiple processes run on one or multiple servers in order to properly manage information storage, at the session or persistent level, you need to use a shared database resource such as central MySQL database or cluster among them. By default Jaxer uses the database for sessions, rather than cookies.
Typically Jaxer and Apache instances are co-located on the same server. They may be split onto separate computers if that fits your overall architecture and performance requirements. State information, such as session data, is stored in the shared database and not in each instance so some consideration should be given to the impact this has during your application design.
Jaxer Process Architecture
Good results can usually be achieved by configuring between three and 10 Jaxer instances on a single machine. One sample configuration we tested was a server with four CPU cores, the best results came by setting the minimum and maximum Jaxer processes to 64 (roughly
(2 * number of CPU cores)^2). You can look at this formula as a (very) rough guide to finding the best setting for your configuration and tune from there. Note that our test had nothing executing on the server other than Jaxer, Apache and MySQL with the latter two only servicing requests from Jaxer.