A client -- or potential client - asked me the difference between Java and PHP which was not very hard to explain even to someone who is not technical. No problem there. The next question was a bit harder and I'm not sure I answered it well.
He wanted to know why anyone would choose to go with a Java based portal like the new Jboss portal which he refereed to specifically over something like Drupal. His reasoning is that there must be a good reason or Jboss wouldn't have created the portal or something along those lines.
My best reason is that if an organization has the in house staff and resources to support a completely integrated Java application from top to bottom and that application is in place and working they are not likely to want to change technologies for their portal installation. In other words their existing technology will dictate their future direction and implementation of new applications. Or something like that anyway.
That's my best reason. I don't really know whether Java really is more scalable than PHP nor do I know whether its faster or what. I thought I used to know but no longer can say that Java is more scalable and certainly its not faster in every instance.
So what are the reasons one would go with a Java portal over a PHP -- specifically Drupal -- based portal if all things were equal -- IE. no existing infrastructure to be concerned with.
Comments
Depends on requirements
This really depends on the requirements and the capabilities of the platforms being looked at.
The Apache Cocoon project, a Java and XML-based system, chose Drupal for their community site, because it had virtually all the features they were looking for out of the box (either in core or through a contrib module).
I know of no other platform -- and definitely no other Java platform -- that has the combined capabilities of Drupal.
Yea and so did Yahoo
Thanks Boris I didn't know that Cocoon chose Drupal as well. It seems that when Drupal is chosen by for instance the Apache Foundation to run an internal site or Yahoo thre is always a caveat that it is because it is full featured "out of the box." But I have a question regarding that. If its full featured out of the box does that mean it is not extensible going further than default type setups? Its seems to be the subtext of these caveats . But I'm here to say its not true. I beleive that Drupal is yes full featured out of the box but that gives it a head start and its just as fast and extensible as Lenya and a whole heck of a lot easier to deal with in a production type of setting. I'm really puzzled by this. I don't know what the limitations are. I know that this risks sounding ignorant but I think I know enough about the modern capabilites of PHP and particularly php 5 to say these things. Is it that Drupal cannot be run in a distributed enviroment. One can run Drupal in a distributed enviroment. True? I can't see why not.
Community vs CMS
Lenya and Drupal are quite different. Lenya is primarily a (promising looking) CMS for XML based content. Drupal is an online community system that can do some CMS type stuff. Although there is a little overlap, they don't compete directly with each other IMO.
The reason all these other Java projects (even the CMS projects) are using Drupal is that they want the more dynamic community features eg blogs, forums, feeds etc. There doesn't seem to be a lot of quality online community stuff in the world of open source Java apps (yet at least). There are pretty good Java solutions for managing content though, especially if you want XML type single source publishing type stuff.
I did an evaluation of JBoss Portal (the beta) a month or two back and hated it. There were next to no docs available, it was appallingly slow even though it didn't seem to actually do much, the HTML output was tag soup at best, it looked very hard to theme etc etc. About the only positive I found was that it seemed like it might integrate well with externally produced content that got uploaded to the server.
I work for a Java development company, but we are using Drupal for our user support site. Set up a quick Drupal install side by side with a JBoss Portal for your client to see and try out - the speed difference alone should make up their mind.
If they are truly fixated on Java and are more focused on publishing than community - steer them towards stuff like Lenya, Daisy etc (even Forrest?). Leave JBoss portal alone - it's just a bad case of Not Invented Here for the otherwise good JBoss project.
Excellent explanation
Thank you.
Server start up time
Many programmers feel that their positions will come under the ax if the process of starting the server doesn't take less than three minutes and spew 150 pages of console jibberish. Other than that it is harder to replace a Java programmer than it is a PHP programmer because the learning curve is higher, so convincing your boss to go with a Java portal is also a good job security strategy.
Besides, as we all know, Nuke architecture was a Good Idea which was only waiting for the magic touch of JBoss and its subsequent porting into Java to become a Great Thing.
- Robert Douglass
-----
If this helped you, please take the time to rate the value of this post: http://rate.affero.net/robertDouglass/
www.hornroller.com, www.robshouse.net
You're exactly right
It wasn't untill Nukes as they called it that I became completely certain that Java has become a black box through which perfectly logical code is passed in order to obsucre everything possible.
Tool vs. use thereof
Before the flame war really gets going keep in mind that Java is a (very good) tool and JBoss-Nukes is one way to (ab)use it.
- Robert Douglass
-----
If this helped you, please take the time to rate the value of this post: http://rate.affero.net/robertDouglass/
www.hornroller.com, www.robshouse.net
php + java
http://www.php.net/manual/en/ref.java.php
--
Ahmed Hashim
Egypt
Ahmed I read that. It sounds interesting.
Do you know of any working examples?. I couldn't find any on the page.
pears and apples
Don't try to compare pears and apples ... But if you really want, here my thoughts:
JBoss and EJB are geared toward totally different markets. If you need
choose JBoss, since you can distribute the components and / or easily build clusters. You will NEVER reach the same level with a PHP based solution such as Drupal, its simply NOT possible. But Drupal and PHP are your solution if you need a simple, understandable system for small and medium sized websites or web applications.
That is an easy question you can answer based on two reasons:
Never? Not possible?
There's nothing stopping anyone from scaling Drupal with clusters. JBoss and Java zombies are sooo full of it when this argument comes up. Want a little bit of proof? Suffice to say that Wikipedia isn't running JBoss:
http://meta.wikimedia.org/wiki/Wikimedia_servers
90 servers (including the 23 from Yahoo!), 100% LAMP.
- Robert Douglass
-----
If this helped you, please take the time to rate the value of this post: http://rate.affero.net/robertDouglass/
www.hornroller.com, www.robshouse.net
sure - but
Of corse you can build clusters even with other solutions than JBoss but its not trivial at all. You are responsible for everything, from replication to failover: You need to install many different services and to configure each of them to work together. JBoss implements all of them in one product (and provides other sophisticated features and services based on a solid architecture). Plz tell me again what solution is better suited for high available and scalable applications, the one requring months of configuration and feasability studies or the ready-to-rumble all-in-one bundle?
You mean...
N webservers, fronted by a load balancer, connected to a backend MySQL cluster with clustering turned on? Yep, sure sounds hard :P
Scale the layers underneath, so it's transparent to the software.
you forgot- replicate
you forgot
- replicate session
- handle failover
Didn't forget
* Sessions are stored in the database
* if any of the Apache servers fall over, load balancer just re-directs to different box
* MySQL is in a cluster, same thing with failover
Next? :P
It's just a different model of scaling
You might want to take a look at this article: Scaling using processes instead of threads
It's about the FastCGI scalability model, which PHP can utilize (though the article is about Ruby on Rails), contrasted to J2EE's scalability model.
We're using PHP apps on a cluster of 4 servers, with 3 diskless frontends running Lighttpd + FastCGI + PHP, and 1 high-end backend running MySQL and providing netboot and NFS services to the frontends.
It works and scales very well (as needed, we can add more frontends with very short notice, since they don't require installation), and setting it up was a good example of the KISS principle in action.
Ironically, "...one requiring months of configuration and feasability studies" is something I would associate with overengineered J2EE solutions and projects :-D
(...originally hailing from that side of the fence myself, though I've been lucky enough lately to escape from Java to Ruby, with a bit of PHP, mostly because of Drupal, thrown in for good measure.)
Thank you Arto
This is a good article. Thanks again.
Thank you Arto
This is a good article. Thanks again.
At what point do you consider it better to go with JBoss
--this is a reply to crac regarding scalibility etc--
over PhP and Drupal for instance. What is the breakpoint? I think its helpful to give real world benchmarks but here is where you realy are talking apples and pears.
Hourly average page views --
bandwidth consumtion --
simultaneous sessions --
what else?
couple others
-- Manhours needed to program simple task X
-- Hourly rate for above manhours
- Robert Douglass
-----
If this helped you, please take the time to rate the value of this post: http://rate.affero.net/robertDouglass/
www.hornroller.com, www.robshouse.net