Joe Walker - dwr tag

Lessons from Hosting a Website

Tue, 22 Jul 2008 16:46:29 GMT

You might have noticed that the getahead.org domain has been replaced by directwebremoting.org. There’s a story behind it ...

3 years ago when DWR started to be successful, I bought 2 identical servers, built them identically with the latest Debian, and latest Drupal, bought some hosting space for one of the servers and kept the other at home as a backup with a nightly rsync, and thought I was doing a good job of managing a website.

The first thing to go wrong was Drupal dropping support for several of the modules that we were using: the theme engine, and the wiki module. So we were stuck on an old version of Drupal unless we spent lots of time recreating the themes and updating all the content. Lesson: 3rd party modules are OK but don't depend on them in a big way.

We realized we needed to upgrade, but it was a big job and when I began talking to the Dojo Foundation about them hosting DWR and talking to SitePen about me working for them, it seemed sensible to do the upgrade when we moved to Dojo Foundation hardware.

Then the backup died. Is it just me or does everyone assume that the live server will die first? We hoped that we could get everything onto the new hardware before the live server died.

The bad news is, but if you buy identical bits of hardware, then there is a good chance that they will have identical failings. That proved to be true in our case and we ended up with a huge rush to get everything moved to new servers, which included a fair bit of downtime. Sorry if it affected you.

I’m not sure if this is a reason to buy different hardware, where do you stop after all? Do you insist on different copper vendors for the power cable? The lesson is - if you discover a hardware fault in some part of a live site, the same thing is likely to happen to other identical hardware.

The good news is that the DWR website is now back on new hardware and a new URL. http://directwebremoting.org/dwr/. We’ve tried really hard to ensure we’ve got re-directs for all URLs, but please give us a shout if you notice that anything is 404ing.

Commercial Support for DWR

Fri, 14 Mar 2008 11:25:36 GMT

Short version: Commercial support and development assistance is now available for DWR.

Long version: SitePen has been offering support packages for a while, but you've had to ask. But it's now an advertised service, if you want help with Dojo, DWR or Cometd, packages start from $995. The DWR mailing lists are not going away and is still going to be a good solution for many problems, but if you need a bit more care and attention, we can now do that too.

The team of people that I'm working with at SitePen are awesome. Aside from the obvious DWR, Dojo and Cometd projects, SitePen people have also created TurboGears, Persevere and JSPON, are working specs for Bayeux, JSON schema and Servlet 3.0, and author json.com and cometdaily.com.

If you need to know more check-out the summary over on the SitePen site.

InfoQ Interview

Wed, 05 Mar 2008 09:13:43 GMT

InfoQ interviewed me, and asked:

What are some of the major features planned for [DWR] version 3.0?
When is 3.0 slated for release? Is it still sometime in June?
What does the incremental release schedule look like before the final 3.0 release?
What are the top small features or fixes in 3.0 that a developer will be thankful for?
For someone who might have looked at DWR 2.0 and decided the time wasn't right, what might 3.0 provide to help "make the deal"?
What happened to 2.1, why the jump to 3.0?
What sort of impact will Tibco's role play in the future of DWR?
What are the next major milestones for DWR after 3.0?

InfoQ is built using DWR, so it would be great if they could take advantage of features like automatic offline when 3.0 comes out.

Taking of things Q. Next week, I'm talking on DWR and Comet at QCon.

DWR + Aptana Jaxer

Tue, 04 Mar 2008 14:29:07 GMT

I've been working with the guys from Aptana for the past week or so on adapting DWR to be a remoting layer for Jaxer.

Jaxer is a way to run JavaScript on the server. But it's not just JavaScript as an alternative to Java/Ruby/PHP/etc. Jaxer is Mozilla, on the server, with it's face ripped off and replaced by a snorkel to serialize the DOM to a web browser. John has a great introduction, or there's the podcast that Ajaxian did.

The vision with DWR was always to say: We've got Javascript in the browser, and Java on the server - lets connect them in the best possible way. This leads to the migration of view logic from the server to the client. But it's not safe to move it all; Validation is part of view logic, but that needs to be done on the server. With Jaxer you can specify scripts to be runat="server" or runat="both" to allow validation or other logic to be run in both places.

Some of the changes that we've made to DWR will only help you if you are using DWR inside Jaxer, but others could be generally useful.

There are 2 basic changes. DWR on the Internet needs to make sure that the Internet only touches the code that you want it to touch. DWR in Jaxer doesn't have this problem because it's not accessible from the Internet, so we can do away with almost all configuration. Secondly latency inside a server-room is tiny compared with the net, which makes synchronous XHR viable.

So as it stands at the moment in development, you can use DWR inside Jaxer like this (clearly this is subject to change):

<script type='text/javascript' runat="server">
Jaxer.dwr.pathToDwrServlet = "http://localhost:8080/demoServer/dwr";
Jaxer.dwr.require("util", "new/org.example.Demo");

function loadServer() {
  var data = Demo.getData();
  dwr.util.setValue('fillFromServer', data);
}
</script>

There are a number of benefits that come out of this even if you're not using Jaxer:

In dwr.xml you needed to specify javascript='ScriptName'. If (as is common) ScriptName == Class.getShortName then you can just drop the attribute, it will default properly.
Cross domain remoting is now automatically detected, and scriptTag remoting is used if needed.
There is a new init-param 'useAbsolutePaths' which might help people with trouble remapping DWR's location.
All URLs are now reconfigurable.
If you are using DWR in synchronous mode (which I don't recommend on the Internet) then you can use returned data in the normal way without needing a callback.

IWebMvc Preview

Tue, 04 Mar 2008 13:16:21 GMT

Jose Noheda has released a preview of a library that glues together DWR, Dojo, Spring and Hibernate/JPA. It's a 0.1 release and he's looking for feedback.

Despite the name, it's not really another Web MVC framework, but more along the lines of AppFuse or Grails, as a way to kick-start a project and provide some sensible defaults without needing to learn everything from scratch.

The source and release notes say it needs 1.6, so Mac heads will need to get the Apple Java6 preview.

Jose's aims:

In my mind what I really needed was a platform that:

Is based on Java
Although supporting Groovy / JRuby is a plus
Helps me to kick start a project
But simplifying the process by giving me the best (and this can be tricky) set of frameworks for each task
Integrates both server and client sides
And it's lightweight, robust and extensible. Read enterprise quality.
Supports all the common tasks a web app has to handle
I include here: User Management, CRUD operations, i18n support (both framework & data), AJAX and astounding visuals

Jose has done some brilliant work on DWR. He created a large chunk of our binary file support, and is currently the Spring integration maintainer, so it might be worth a download to see if it can help you.