My current project involves building a commercial Java Web application. For years I’ve built Web applications (using Java and a number of other platforms) to deploy on our own servers. Building something that’s suitable for distribution is a horse of a different color. I thought I’d write up my experiences for other people who are taking on similar tasks.
- Distribution format – Usually Java applications are distributed as WAR or EAR files, but many people also package their Java Web applications with a servlet container to run them to make things easier.
- Open source licenses – My application uses a number of open source libraries, and I had to go through and make sure that all of the libraries were distributable without much fuss.
- Configuration – What’s the best way to set up database connections and other configuration parameters?
- Deployment platform – In theory, Java Web applications should work with any servlet container, but the devil is always in the details. Many Java applications seem to be distributed with a servlet container as well. What’s the best approach?
Look for separate posts dealing with each of those issues.
I’m sure other considerations will arise as well, but those are the first few that have cropped up as I’ve started working on this.
Embarking on this process makes it clear why PHP has become the dominant platform for writing distributable Web applications. Regardless of its strengths and weaknesses as a development platform, its deployment story is hard to beat.
There are no real questions when it comes to distribution format. You archive the files and put them up for download. The end user downloads the archive, expands it, and puts the files in the directory where they want the application to appear.
As far as licenses go, many PHP applications have no external dependencies. PHP provides all of the functionality you need for most applications, and PHP developers have never really taken to using libraries to make things easier. Java developers tend to use tons of third party libraries, and Ruby on Rails applications often depend on dozens of Gems. PHP developers use what’s available as part of PHP and that’s it. PEAR is out there, but it isn’t terribly popular. I assume that’s because so many PHP applications are deployed on shared hosting. It’s just not worth the risk to bring in dependencies if you don’t have to.
Configuring a PHP application usually involves editing one heavily commented PHP file. Most people consider that to be inelegant, but it’s hard to argue with the simplicity.
PHP is ubiquitous, so there’s not much to worry about in terms of deployment. You just need Apache with PHP support.
When you look at those factors as compared to Java or Ruby, it’s easy to see why PHP maintains its massive popularity over other development platforms, and why we see explosive growth among applications built using PHP, like Drupal, WordPress, and MediaWiki. For all its drawbacks, PHP has evolved in a world where simple deployment and configuration are both hugely important, and that has given PHP some powerful advantages that other platforms aren’t even trying to compete with.
January 28, 2011 at 2:10 pm
Couldn’t agree more. Ease of deployment is one PHP’s greatest strengths.
January 31, 2011 at 6:54 am
Perhaps the reason PHP has such ease of deployment is that it hit the scene at about the same time as Apache (1995 for PHP, 1996 for Apache) so they could mostly develop in tandem. Java, Python, and Ruby are all older (although I was surprised to learn Java’s first release was in 1995, according to Wikipedia). It may all just be a matter of timing and coincidence. The web looked very different in 1995 and no body knew the prevalence Apache would come to have.
January 31, 2011 at 3:04 pm
Perl was a similar case before CPAN got crazy big and everyone started using 300 libraries and installations became a nightmare and everyone stopped using Perl.
Java is basically in the same spot. Early on in my usage of it, I used a lot of libraries because, well, they were there. In recent years I have pretty much dropped the use of significant numbers of third-party libraries in favor of just writing the damn code myself (for many of these cases, actually simpler than learning & configuring a library) or making a private fork. (The latter doesn’t help you with licensing of course.)
Anyway, I think you have the right list. Including a servlet container like Tomcat is almost certainly essential; you may want to ship the database as well, for the same reasons – configuring app servers and databases is a pain in the ass and significantly limits the number of sites that can use your application.
Getting config into WAR files is fun, as I’m sure you know; at least the last time I looked, support for external configuration of applications was extremely variant across different application servers – I was only looking at Tomcat and Websphere and the differences were driving me crazy.
So I would ship with the app server and database if possible and make it clear to any customers who know what they’re doing that you will support them in repackaging or reconfiguring the system if necessary.
Depending on what it does, you may want to look into shipping it as a “library” instead of a “web application”, even if it still provides a web interface. So much Java software goes into custom systems that a library might be more appealing for many integrators, and thinking of it as a library will also make you think about how to provide those external integration access points.
Personally I don’t think I would be up for shipping a Java application as a product right now. I had so much pain the last time I did it and the customer was so unhappy that I just couldn’t face it.
July 7, 2011 at 3:11 am
“distributable” in Java it means that your web application can be installed in a cluster in order to scale for best performances and availability. I am not aware if PHP provides any availability setting, anyway Java is a platform for enterprise applications and in my opinion it is the best choice today for important and huge solutions. For simple web sites there are several choices Java compatible or competing technologies like PHP and ASP.