Aptana has been known for its Eclipse based Ajax IDE Aptana Studio. Paul Colton, CEO, has impressed us at The Ajax Experience as he has shown of Studio, and how Aptana is fast to adapt and come out with support for iPhone development, Adobe AIR, and more.
But today Aptana is breaking out of the IDE world, and joining the server market with the release of Jaxer, which they are calling an "Ajax Server". Jaxer brings JavaScript, the DOM, HTML, CSS, to the server as it tries to unify the development model for developers.
You can think of the server as a Mozilla version of Tomcat. It plugs nicely into Apache (and more in the future), and handles the web application requests for you.
An example: validation
One solid way to understand Jaxer is to look at an example such as validation (screencast). Wouldn't it be nice to be able to reuse your validation logic on the client and the server? This example shows you how you do just that:
Part 1: Server Proxy
This code shows you how to use runat="server-proxy" to wrap that code in a way that the client can call it, but it gets seamlessly ran on the server:
If you don't like context switching between the Web world of HTML/CSS/JS/DOM (Ajax) and the server side language of your choice, then this could be the programming model for you.
Unobtrusive Ajax
There are some interesting benefits, such as the ability to do a good job with certain accessibility without much work. If the browser doesn't have JavaScript turned on, the server can run the code and produce the HTML for you. Obviously, the HTML interface that is returned would be less dynamic.
The execution flow looks like this:
Prototype/jQuery/Dojo/... on the server
You can use your client-side library of choice on the server (e.g. Prototype, Dojo, jQuery, etc). My screencast below in fact does just that. The aim isn't to create a totally new programming model, but to rather be part of the Web. That being said, they had to add a set of libraries to allow you to do things on the server that you can't on the client. For example, the file reading in the example above: Jaxer.File.read("name.txt").
Databases
To build server side Web applications you normally need to persist data. Database access is provided via Jaxer.DB.*, and SQLite is built in. As soon as I saw this, I pictured a wrapper for Jaxer that would bridge the Google Gears database API. There is the ability to build some simple syncing, and have the framework do the right thing depending on if you are offline or online, and shifting data between the local and remote SQLite database. Very promising.
Cross domain XHR
Since you can have XHR calls which are really coming from the server, you can talk to any domain. Again, in my example, I proxy through to Twitter, which allows me to do a Greasemonkey type solution that works in all browsers.
JavaScript 1.8
Since the latest Spidermonkey is available on the server, you can write JavaScript 1.8 using new features such as expression closures, generators, and more. You have to be careful here and remember that this will only work for code ONLY running on the server. For all other code, you have to do the usual thing and test it with the various browsers that matter to you.
Rails for JavaScript?
I hope that we do not see a lot of huge pages with runat="server" all over the shop. We did that in the ASP/PHP/JSP of old. I am sure that frameworks will pop up to do MVC nicely with Jaxer. One option would be having Jaxer work nicely with projects such as Trimpath Junction and the project that Steve Yegge often talks about.... which is Rails-like but for JavaScript (using Rhino). Integration will also be an issue for a certain class of applications. I can imagine there being a particularly strong connection for something like Java.
IDE independence
Although Aptana Studio has top notch support for Jaxer (it better!), the product does not depend on any IDE and you are free to use it with anything. To show this, I use the stand alone Jaxer server and write my code using vi.
In fact, let's check out the video that builds a Twitter proxy in a few lines of code, showing how the beast works.
(I recommend watching the video at Vimeo to make a larger window to see the type).
The new release is huge, literally, since it has gone from < 150 KB back in 2005, to 5.3 MB today. This is mostly due to the new server side code based on Helma.
If your end-user has Google Gears installed, they can execute the web-app primarily within the web-browser. Here, the client-side RDBMS is an asynchronously replicated cache of records from the main server-side RDBMS. The big benefit is increased UI responsiveness. And, the web-app can go offline and survive down or flaky network connections. By flaky, I’m thinking iPhone on AT&T, or 200 attendees trying to share a conference WiFi hotspot.
If your end-user does not have Google Gears, no problem. They can still execute the web-app completely within the web-browser, for increased UI responsiveness. And, the web-app can still survive flaky network connections. Here, the client-side RDBMS is not persistent, just a memory-only SQL engine. The downside with a memory-only DB is you can’t truly go offline where you power-cycle, or close and restart your web-browser.
The last option is where your application code executes on the server side, running on a traditional-style, server-side web application server. It communicates directly with the full, main RDBMS that is the source of truth. While not as snappy as the browser-hosted web-app, at least the user is working with the full set of data, not a cached subset, minimizing outdated views of information. Also, the pages served up by the web application server are crawlable, if you wish, by your favorite search engines.
I met Steve Yen a long time ago and we chatted about Junction as well as other topics. He is a very smart guy, and it is great to see him back in the TrimPath game..... at the perfect time.
Greg Wilkins, the creator and maintainer of the popular Jetty servlet container (i.e., a Java web server), has written a blog entry announcing Jetty's support for the Comet design pattern via Cometd:
Cometd is a scalable HTTP-based event routing bus that uses a push technology pattern known as Comet. The term 'Comet' was coined by Alex Russell in his post 'Comet: Low Latency Data for the Browser'. Cometd consists of a protocol spec called Bayeux, javacript libraries (dojo toolkit), and an event server.
Jetty now has just an implementation of the cometd event server that uses the Continuation mechanism for asynchronous servlets.
Greg also uses the blog to urge the creation of client and server APIs for the Comet pattern:
to achieve true interoperability, we will need to develop standardized APIs on both the client and server side. Having standard protocol is a start on this, as it defines the capabilities that will need to be expressed in the APIs
Agile Ajax has posted an interview with the creator of ZK, the server-side GUI framework for writing ajax apps with "no javascript and little programming". ZK has some similiarities to Echo2 and GWT, though Tom Yeh, the creator, discusses the differences:
on Echo2:
Echo2 assumes UI designers are Swing programmers, while ZK assumes they are mostly non-programmers
on GWT:
From a technological viewpoint, [GWT] is a complement. GWT is a client-side solution and quite good for developing Ajax components. It is never a good idea to replicate the business logic to the client, which eventually brings us back to the maintenance headache of fat clients. In addition, loading and evaluating huge JavaScript files into the client is not fun at all.
The interview goes on to cover the strengths and weaknesses of ZK, Dojo and Atlas, and future plans for the framework. He also closes with a common complaint about the Ajax community - the over abundance of frameworks and resulting confusion. A chart breaking down the major players and their pros and cons would be a great help to many developers who are trying to figure out where to start.
Ben Joldersma has announced release 0.1 of the Emerge Toolkit, an Ajax web framework targeting C# and Dojo. The current release targets C# 2.0 and Dojo 0.2.2, with plans to update to the latest Dojo 0.3 release by July. Browser support includes Firefox, IE, and Opera, with partial Safari support.
Instantaneous, two way communication between server and browser with Comet transport
100% C# 2.0 - Write your application in your favorite CLR-supported language.
Build application logic with existing widgets (built on Dojo) or roll your own.
Create interfaces in C# or XML, and style them with CSS.
Integrated O/R mapper - write your models in C# or XML. Store them in an embedded SQLite database, or soon MySQL or SQL Server
Prototype applications rapidly with our Scaffold (inspired by Rails) and other data bound widgets
Present data visually with SVG widgets, with plans to use Dojo's VML compatibility layer
Tie everything togther with live data binding services for simultaneous event updates
Billy Newport recently kicked off a conversation about Ajax and its impact on servers.
I think it's becoming clear now that AJAX enabled applications generate a higher load on an application server than a non AJAX application. I guess customers will have to size their boxes appropriately as a result. The problem is related to the fact that an AJAX enabled pages simply send more requests to the server because of their high level of interaction versus a conventional web page.
Some AJAX sites fetch all the data and then display it in an interactive fashion. Others will fetch a reduced set of data and then pull the missing data when it's requested. It's the latter where care needs to be taken. Lazy data fetches are great from a user point of view. They are fast, they make the app responsive. But, if a lot of data is fetched lazily then this is a high overhead way of fetching the data. It may work well under low load but as load increases, the servers may slow down unacceptably due to the extra overhead of high frequency/low content RPCs.
Considering that Basecamp ran on one server for its first year, I’m curious what causes him to make a statement like that. I’m not saying there isn’t some truth to it, but I haven’t been hearing any screaming about this issue; I’m not sure, but I suspect Gmail gets a few hits a day and it seems to be doing OK…
The question is dangerous because it’s meaningless and unanswerable. Your typical Web page will, in the process of loading, call back to the server for a bunch of stylesheets and graphics and scripts and so on: for example, this ongoing page calls out to three different graphics, one stylesheet, and one JavaScript file. It also has one “AJAXy” XMLHttpRequest call ... I’ve argued elsewhere that AJAX can be a performance win, system-wide; but that argument too is contingent on context, lots of context.
An Ajax app doesn't have to be like Google Suggest and respond to (almost) each keystroke. But there are times when a high level of interactivity is the ideal thing for users, and at least for those situations, it's important to look at strategies for scaleability and optimal performance.
Ajax framework maker JackBe is expanding its business to include a consulting component, and has just announced some significant hires away from Sun. John Crupi, formerly Sun's Chief Java Architect, is among three engineers heading over to JackBe. All three - Crupi, along with Deepak Alur and Dan Malks - are the authors of Core J2EE Patterns (highly influential book in the J2EE world).
Interesting to note the emphasis here is not so much on client-side Javascript as overall architecture and SOA - that's the predominate skill of the new hires, and that's where JackBe is heading.
To get a head start on the emerging trend of AJAX and SOA integration, JackBe, one of the early AJAX supporters (it had one of the first AJAX tool kits available on the market), has recruited three of Sun's top Java/SOA engineers, including Distinguished Engineer and Chief Java Architect John Crupi.
Crupi, who also was former chief technology officer of Sun's Enterprise Web Services Global Practice, joins JackBe as the company's CTO. Deepak Alur, a Sun principal engineer who led Sun's SOA initiatives and was lead architect for implementing eBay's V3 project, joins as JackBe's vice president of engineering. Dan Malks, also a Sun principal engineer, joins JackBe as vice president of solutions and strategic development.
JackBe was founded by Luis and Jacob Derechin in 2001 ... Our considerable experience with these large enterprises convinced us that the real value of AJAX we bring to our customers goes far beyond simple enhancements to the front-end user interface, and involves more comprehensive solutions that integrate AJAX, SOA, and other advanced technologies into complete solutions.
This time around he moves beyond threads, and talks about buffers.
Operating Systems & Connections: Choose your TCP/IP stack wisely remember when you used to buy a TCP/IP stack? :)
Connection Buffers: Significant memory can be consumed if a buffer is allocated per connection. Memory cannot be saved by shrinking the buffer size, which is a good reason to have significantly large buffers.
Split Buffers: Jetty 6 uses a split buffer architecture and dynamic buffer allocation. An idle connection will have no buffer allocated to it, but once a request arrives an small header buffer is allocated. Most requests have no content, so often this is the only buffer required for the request. If the request has a little content, then the header buffer is used for that content as well. Only if the header received indicates that the request content is too large for the header buffer, is an additional larger receive buffer is allocated.
Gather writes: Because the response header and response content are held in different buffers, gather writes are used to combine the header and response into a single write to the operating system. As efficient direct buffers are used, no additional data copying is needed to combine header and response into a single packet.
Direct File Buffers: Of course there will always be content larger than the buffers allocated, but if the content is large then it is highly desirable to completely avoid copying the data to a buffer. For very large static content, Jetty 6 supports the use of mapped file buffers, which can be directly passed to the gather write with the header buffer for the ultimate in java io speed.
Great to hear from the server side folk like Greg of Jetty on implications like this.
What implications have you come across?
Have you tweaked your server settings a lot to get that extra bit of performance out of the server side of your ajax app?
The 6.0.0alpha3 release of Jetty is now available and provides a 2.4 servlet server in 400k jar, with only 140k of dependencies (2.6M more if you want JSP!!!). But as well as being small, fast, clean and sexy, Jetty 6 supports a new feature called Continuations that will allow scalable AJAX applications to be built, with threadless waiting for asynchronous events.
Ajax polling problem
But there is a new problem. The advent of AJAX as a web application model is significantly changing the traffic profile seen on the server side. Because AJAX servers cannot deliver asynchronous events to the client, the AJAX client must poll for events on the server. To avoid a busy polling loop, AJAX servers will often hold onto a poll request until either there is an event or a timeout occurs.
Thus an idle AJAX application will have an outstanding request waiting on the server which can be used to send a response to the client the instant an asynchronous event occurs. This is a great technique, but it breaks the thread-per-request model, because now every client will have a request outstanding in the server. Thus the server again needs to have one or more threads for every client and again there are problems scaling to thousands of simultaneous users.
Jetty 6 Continuations
The solution is Continuations, a new feature introduced in Jetty 6. A java Filter or Servlet that is handling an AJAX request, may now request a Continuation object that can be used to effectively suspend the request and free the current thread. The request is resumed after a timeout or immediately if the resume method is called on the Continuation object. In the Jetty 6 chat room demo, the following code handles the AJAX poll for events:
private void doGetEvents(HttpServletRequest request, AjaxResponse response) {
member = (Member)chatroom.get(request.getSession(true).getId());
// Get an existing Continuation or create a new one if there are no events.
boolean create=!member.hasEvents();
Continuation continuation=ContinuationSupport.getContinuation(request,create);
if (continuation!=null)
{
if(continuation.isNew())
// register it with the chatroom to receive async events.
member.setContinuation(continuation);
// Get the continuation object. The request may be suspended here.
Object event= continuation.getEvent(timeoutMS);
}
// send any events that have arrived
member.sendEvents(response);
// Signal for a new poll
response.objectResponse(\"poll\", \"\");
}
When another user says something in the chat room, the event is delivered to each member by another thread calling the method:
class Member
{
public synchronized void addEvent(Event event)
{
_events.add(event);
if (_continuation!=null)
// resume requests suspened in getEvents
_continuation.resume(event);
}
...
}
Great to see server vendors helping us out on issues that come about from the new paradigm!
There is more afoot with messaging and Ajax. ActiveMQ is an open source MOM, and it now has support for Ajax.
Ajax support in ActiveMQ builds on top of the REST connector for ActiveMQ which allows any web capable device to send or receive messages over JMS.
Client side view
On the client the web browser uses a simple JavaScript library which uses XmlHttpRequest to make calls on the REST API to send or receive messages.
This means that the DHTML client can send or receive messages asynchronously from the users interaction and can easily databind XML messages received with the HTML DOM to produce some revolutionary applications all with standard DHTML technologies.
The web browser can then render active views of information which can update in real time.
Server side view
Here each HTTP GET or POST is just a regular use of the REST API and so doesn't particularly care what the client is; whether its JavaScript or C or Ruby/Python whatever.
We use a MessageServlet on the server side to handle the HTTP traffic; together with an optional NIO based servlet engine (Jetty) for handling large numbers of concurrent clients.
On a site note:LogicBlaze is a new company that recently got funded by Simula Labs to offer support and services around Active* products.
, Server
