Jaxer is the Aptana Ajax Server, and it's also built into Aptana Studio. Jaxer allows you to execute JavaScript on the server, before the page is served or during a callback. Now you can write your entire application, or your presentation layer, using a single, familiar Ajax codebase. It's standards-based and available under an open source license. And your pages that don't use Jaxer features will be unaffected by running it through Jaxer.

Rich web applications and sites deliver great value but are hard to develop, deploy, and maintain. The client side of the application or site requires careful coordination of complex DHTML, JavaScript, and CSS—Aptana Studio is designed to greatly ease the client side of this pain.

Power of a JavaScript Server

Jaxer completes the picture by enabling you to:

• Develop your entire site or application using only standards-based DHTML, JavaScript, and CSS;
• Prepare the HTML DOM on the server before the page is served, using the same techniques and libraries you would use on the client;
• Call server-side JavaScript functions directly from client-side JavaScript;
• 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

JavaScript functions on the client call JavaScript functions on the server to fetch database information, manage sessions or, as needed, access back-end Java business objects and network resources. The DOM can be prepared on the server using the same Ajax libraries (such as jQuery, dojo, Prototype, YUI and EXT JS) as used on the client.

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

Jaxer's capabilities are possible because its built on top of the Mozilla SpiderMonkey engine, the same technology used inside Firefox, and so natively supports DOM manipulation, JavaScript execution and CSS. Jaxer affords an extensible and future-proof platform for building dashboards, optimizers, and compliance filters for use by IT and marketing organizations across multiple legacy web applications.

Examples of using Jaxer as a post-processor

• Intelligently instrument the outbound HTML stream for monitoring performance and user experience and behavior
• Optimize the application (for example by aggregating JavaScript and CSS files to minimize network delays)
• Enforce security and compliance requirements
• Add new capabilities that were not designed into the original application

Jaxer Scalability

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.

For performance testing information on Jaxer, please refer to our blog post First Jaxer Benchmarks.