What Perl Could Learn from Java WARs

| 7 Comments

A business partner convinced me to work on a short-term Java web programming contract with him, and the details were right. (My most recent Java programming experience was an experimental project for a very large middleware company a couple of years ago that gave them a lot of information at the cost of a lot of frustration.)

The experience has been enlightening.

One bright spot is Java's notion of web deployment. It has its obvious flaws, but it has obvious benefits. You gather all of the artifacts necessary for your project: XML files, JAR files (bundles of Java libraries), web templates, the classes you've written, and other resources, all in the appropriate subdirectories governed partly by convention and partly by a manifest file. Your deployment process bundles everything up in to a WAR file (a web archive). Then you dump this WAR file into an application server.

Compare that to another project I delivered recently where I sent a CPAN-style distribution tarball to a (much more technically savvy) client, who set about installing dependencies from the CPAN (where Module::Install couldn't get the job done) and from yum, where you don't want CPAN installing, for example, PostgreSQL for you.

Granted, I could have used a tool such as Shipwright to bundle my code, but I didn't. For better or worse, CPAN-style distribution is awfully common.

Imagine instead if I could have bundled everything up into a single WAR-style file which a hypothetical Perl web application server could deploy.

Java achieves this in at least two ways. First, Java wants to own the world—Java does have bindings to native code, but the Java desire to have pure-Java everywhere tends to encourage people to write pure-Java code where Perl hackers might write XS. (XS means you have to compile native code on the target deployment platform.) Someday perhaps Perl 5 can reduce its reliance on XS.

Second, Java application servers also have the advantage of a stronger memory separation between different applications running on a single JVM. Some of this is due to the static nature of the Java language. When you can resolve all references within an application at load time, you don't have to look things up by strings in a global directory. (Of course, you do have to be clever in your VM design to allow runtime reflection, so the implementation of the VM is also important.)

Plack offers a way around this. Imagine a Perl app server based on Plack to which you can deploy multiple applications. The app server could start multiple independent backends—even so far as having multiple installations or at least library directories for each application, as necessary—to use Unix process separation to achieve this memory separation.

Such an approach would still likely use less memory than Java.

Make the Plack app server a reverse proxy capable of serving static files and SSL and redirecting invalid requests and you might have something really exciting. (Make it cloud aware and give me a 10% equity stake.)

These are idle musings, and the Java ghetto doesn't tempt me to ditch the world of Perl for a work life full of beans and mappers and inversion of control governed by there's-no-angle-bracket-shortage-in-this-sea-of-XML—but even in that mess, there are still some good ideas worth borrowing, buffing, and bettering.

7 Comments

It seems to me the thing that is missing in the perl case is a cute name for the functionality. Those who deploy perl code to apache webservers have been doing it as a hierarchy of files containing code, templates, resources & such for years. One of the places we stumble is the boundary between what we expect to be on the server and what we have in our code. The other thing we stumble on is TIMTOWTDI. Maybe it is time for a self appointed BDFL to tell us The One Right Way.

I've deployed plenty of code as a big bundle of resources too, but having only one (admittedly large archive) file to send to the server to install--without having to install my code's dependencies explicitly on the server--is an advantage.

Don't we already have something similar like PAR (Par::*, Apache::PAR::Static) or, to a lesser extent, FatPacker?

Apache::PAR is IMHO a nice approach but works only with Apache... I'd love to have something that works with any *CGI capable HTTP Server (for example lighttpd).

And yes, chromatic, I totally agree with you about everything in this posting. Thanks for putting it together!

I have tried to publish my applications as a set of distributions on a private mini cpan, and deploy from there via normal cpan shell installs on the production server. This turned out to be more difficult than expected with Catalyst apps, but not impossible (use File::ShareDir to store contents of the 'root' folder, and a subclassed ConfigLoader to get to the config file).

Ok, this is what you get when Plack meets PAR. ZOMG!
https://github.com/miyagawa/Plack-App-PAR

(Note that i whipped this up in half an hour, and could have serious limitations and bugs :D)

Modern Perl: The Book

cover image for Modern Perl: the book

The best Perl Programmers read Modern Perl: The Book.

affiliated with ModernPerl.net

Categories

Pages

About this Entry

This page contains a single entry by chromatic published on March 23, 2011 10:38 AM.

Why PSGI/Plack Matters (Testing) was the previous entry in this blog.

The User Experience of Login is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.


Sponsored by Blender Recipe Reviews and the Trendshare how to invest guide

Powered by the Perl programming language

what is programming?