Slashdot Mirror
Ask Slashdot: Which Java Applications Server?
MistaBobDobalina asks:
I am looking at three open-source Java
application servers for the purpose of
building a database-driven website:
Locomotive
,
Protomatter, and
Enhydra.
I am curious if anyone has experience with
these or any other open source middleware
solutions. I am also looking at commercial
products but prefer an open product. I am
making this query because three-tiered sites
are now the norm for E-commerce and this is
an area that the Open Source world hasn't
addressed as well as operating systems,
web servers, and databases have been."
webmacro
Not true by any stretch. I do quite a bit of my mysql db maintenance scripts/code in php and just run it via the command line version (for cgi instalations). The apache compiled version along with the cgi implementation do wonders for both realms.
Granted, I wouldn't classify it as a GP language, but it's damn close to the extent that I often have to decide between it and perl. Would I use either for writing a full and local app with UI? Probably not. But on the server it's handy as hell.
rodent...
Tactical nuclear weapons are a viable alternative!
Posted by smsilver1:
We use Apache JServ 1.0 in a standard 3/4 tier environment. Right now we don't need state migration or complicated fail over/load balancing. (We will soon). We modified Jserv to do JDBC connection pooling, thread pooling, and probably will do socket pooling. I should have some benchmark numbers next week if anyone is interested.
We use a handful of jsp's and servlets for dynamic content.
It will start to be tricky when we need proper state sharing/persistence/failover. We probably won't ever use any remote method invocation mechanism.
So we're in the boat of needing about 1/2 of the complexity of an application server...given the complexity of debugging these things, i feel more comfortable with access to the source.
Well, the company that I'm contracting for is going to be using Enhydra for 3 out of 4 of our major services so if it doesn't work we're screwed (put another way, if there are bugs that would keep it from working for us they will be fixed by us). However, from what I've seen so far Enhydra looks like a solid system and the design is very impressive. The people who developed it did so over the course of several years as part of their real-life contracting work so that alone would strongly encourage it to be highly stable with a pragmatic design. My experience with it is limitted to a few weeks so I'd be interested in what experiences others have had, but so far I've only been really impressed with it.
Not only is it well built, but their web page also looks very professional. That may be a really good selling for your boss as it's something you can't say about a lot of open source projects.
-----
Free P2P Backup, Windows & Linux
PHP is nice for simple apps, and I use it myself for a lot of things. However, I wouldn't want to use it for a large project as I have tried it before and most of my time was spent being really frustrated with things not working right. The majority of the time the frustration was due to typographic errors on my part, which made me realize what an incredible amount of time strong type checking in languages like Java save me. PHP's slut-like view of casting also caused me infinite grief - when "" can be interpretted as "", 0, null, or false it makes database queries (among other things) a royal pain. I also found a lot of the functionality of the methods counter-intuitive, but I suppose that wouldn't be a problem if I were more experienced with it. The other thing, which I know has been mentioned already, is that PHP mixes code and HTML quite thoroughly which can be a real problem if you have a software team working on the functionality of the web page and a graphics design team working on the look and feel and they won't necessarily be working closely (this is common).
Anyway, I don't mean to be down on PHP because I still like it and use it. I just wanted to give you some ideas of why it's not right for every job.
-----
Free P2P Backup, Windows & Linux
I'll have to agree with what's being said elsewhere. We've been using Java for two years to run some fairly high-use sites (http://highwire.stanford.edu/ and all the sites linked from there), and although it's not perfect, it has given us very acceptable performance even when under heavy load.
Our system is currently using only Apache with mod_jserv (running on Solaris 2.6); we will probably be moving some of the code to an application server environment within the next year.
The most important thing for getting good Java performance is to use the right VM. We were using the Javasoft reference VM when we first started our switchover, and the performance was terrible. When we switched to the tuned Solaris production VM, everything magically started working acceptably.
I expect we'll get another speed boost when we upgrade to HotSpot sometime soon.
Make sure that your VM has a JIT. If you're on Linux, I'd recommend looking at the new IBM JDK; I don't believe the standard Blackdown JVM has a JIT.
I am Jack's complete lack of surprise.
Thnking of Java as 'interpreted' is somewhat wrong. Java actually runs on top of a virtual machine, just like Smalltalk, UCSD Pascal or the MVS operating system. There is a Java Machine Specification, that talks about machine instructions, op-codes, threads, etc.
One of the hottest markets for Java applications will probably be embedded systems. By coding in assembler, you gain about 35% (avg.) size advantage and significant speed (we haven't benchmarked this yet). These features are required--heck no, loved--by embedded system designers.
Once you start coding in Java assembler you can discover a lot of redundancy in the compiler/class files, and you can do away with it to gain the speed/size advantages. Finally, most assembler code can be tweaked against most decompilers without hurting readibility if you get the sources in assembler.
I ranted about business requirements in my original posting, above. There are a couple of companies we know of producing picoJava chips (microcontrollers) and Sun announced MAJC (*magic*), a Very Fast DSP-enhanced Java chip for consumer devices (RISC, 256 registers, *very high* clock speed). Now, imagine Java running on a machine based on this technology... And imagine that your code can run in a PC or a Palm V as well, without changes...
We use Jasmin for our assembler development and we're extremely satisfied. Our code runs on everything from a Palm V with Spotless to an HP/9000 mainframe without changes. Very Cool.
Cheers!
Eugenehttp://eugeneciurana.com | http://ciurana.eu
The URI is http://gamora.org
From the Gamora readme:
EJB Servers are complex beasts to do properly, I spent most of last year fighting with a buggy Sybase EJB server to discover that management decided that it was too expensive...
I hope your goes better
DWR is Ajax for Java
From their site: As of now we have about 60% of the functionality outlined in the spec. Namely we have the containers in place and the managing infrastructure. However we are missing the entity beans (which are optionals right now). The latest build is 0.04 and is the first public release of ejboss
From the web site The XS Server (eXtensible Server) is a framework into which a multitude of different services can be put. These services can then make use of each other in order to implement a certain function. For example, an EJB-service would require JNDI- and JTS-services to be available. By building the server in a modular way implementations can be replaced on the fly.
From their web site: Briefly, Gamora is intended to be a server to end all servers. The idea sprung from a late night coding session of a server for a Java app when I realized (As I had probably many times before) that I was writing the same code every time. So, I thought, why not provide a framework for building servers that drastically slashes the time it takes to create servers.
DWR is Ajax for Java
For more information, go to the Jakarta web site.
- Sam Ruby
A little work and you could turn that post into a haiku...
I have to agree with this. All the middleware proponents should look at Phil Greenspun's book (the photo.net link) before spending large amounts of their employers' money on such solutions.
I don't agree with everything PG says, but I think he's dead right when he says that no amount of expensive middleware can replace proper application design methodologies.
As for machine redundancy and distributed RDBMS transactions, chances are if you can't work out how to do this using a solid RDBMS and well though out transactions, your application server vendor's programmers can't either.
It amazes me that Java Servlets and Beans are seen as the ants pants for web applications by so many. You have an immature and resource hungry implementation the subject of which is being fought over in court on several fronts and the focus of a concerted fragmentation effort. As a language for networked and distributed applications it sucks in several areas.
I had for one ecommerce project to implement a non-blocking socket interface to a proprietary piece of hardware and vendor-supplied software - this CAN be done in Java but only with a pathetic kludge using socket timeouts. My other option was to use COM to interface with an Active X wrapper which can only be done in Java using Visual J++ (ECCCH) or expensive middleware like Linar.
Instead I wrote Delphi and Perl clients. Both are rock solid.
Rocket science middleware is no substitute for careful design and prgramming.
Eagles may soar, but weasels don't get sucked into jet engines.
Locomotive
Protomatter
Enhydra
this space intentionally left blank (oops)
- You don't have to use the whole app server. There are many different parts (jddi, xmlc, standarddatabasemanager, data object design studio) that can be used separately with any Java project you are working on.
- Data access couldn't be much easier. A graphical tool is provided for doing object/relational mapping on existing databases, as well as constructing new databases from an Object design standpoint.
- EJB support is on its way. The Enhydra team is working on a demo of EJB support in Enhydra. This will most likely tie into EJBOSS
I've been very pleased with Enhydra, and I feel that the Enhydra community is only in the beginning phases. With a little more involvement, it is set to take off in a big way. It's certainly worth a download, just to check out the various components and determine their usefulness to you.Hey,
;-)
;-)
I wrote the protomatter stuff, and so I'm pretty biased. PAS (Protomatter Application Server) is a good tool if you're doing simple data-driven site with servlets or JSPs.
It's really designed to only work with Apache JServ, but *should* work with pretty much any web server that supports servlets (it is a servlet itself).
It's main features are:
- Full-featured JDBC connection pools
- Simple JNDI implementation
- Startup/Shutdown classes
- Hierarchical event trees
- Cron-like scheduling
- Robust logging
If that's what you need, then use it. It doesn't support EJBs (and probably never will). It's been used on several production sites, and seems to be quite nice (IMHO
One caveat is that there is exactly one developer for it: me. I've recently taken a new job where I travel about 99% of the time, so I may not have much time to devote to it in the future, but what's there works and works well.
It's also worth noting that the connection pools and logging system are both easily usable outside of PAS, so you could just use those packages in some other app server.
Anyway, it's just kinda cool to see my stuff show up on slashdot
see ya,
-nate
Just FYI, Apple's WebObjects won the Java Developer's Journal Reader's Choice Award for Best Application Server. Definitely worth a look.
I know that the hype around Java says that it's slow, but it just isn't true in the app server world. Java is what most of the major commercial projects use as their development language. A lot of major e-commerce sites run on Java based deployments.
Some tests that I've seen indicate that Java only runs 10-15% slower than C/C++ on a good application server. And considering that Java is so much easier to develop in, I think that this tradeoff is worth it. And that was before HotSpot. Once HotSpot is integrated into application servers that performance gap may not even exist. (Yes Java is slow when used for applets, but that's a much different environment.)
And actually, an Apache (and asumably mod_perl) mySQL combination is never going to give you the scalability that a commercial appserver and ORACLE combination can give you. The clustering features of most decent app servers combined with the massive parallelism features of ORACLE just can't be beat if you have the money to spent.
That being said, there are lots of great open source solutions, both for high scale and moderate scale deployments. I just wanted to dispute the claim that Apache/mySQL will be more scalable than any Java-based solution. I've worked with both, and the Java-based solutions were able to scale much further.
I'm too lame^H^Hzy to attribute and reply to this post properly... sue me
Several good points made here... I think the most important one being that yes, at some point Sun will lose the iron grip on Java that they now have. Don't know if I will personally like it any better then, but a lot of others probably will.
Separating good ideas from politics should become part of the core curriculum for anyone who wants to hack profitably [1] in the world in which we live today. The source of a good idea does not make it less good. It may make it less accessible to some if the source wants you to pay for it, or control how you use it, but it is still good (else why would you care whether you could use it at all).
[1] don't even flame me on this... you like to eat and have a home stocked with unlimited Mountain Dew and Coke Classic just as much as I do
"We're an apex predator with the fecundity of a base level herbivore... We're a virus with shoes..." RazorJAK
We built our site with their stuff, and it's quite good. they've got a page syntax that completely separates Java from HTML, so your graphics people can focus on the appearance of the site, and your programmers can focus on backend, and delivery of the data. They've also got "PersonalizationStation", which allows you to immediately create user profiles out of the box -- and dynamically target your site based on those profiles. (In other words, counting the number of logins that a person has to your site, and changing the front page from "Welcome to our site" to "Welcome back" is about a one-liner.)
Remote admin? No problem. The "component browser" uses bean introspection, allowing you to look at -- and change! -- any object in the system, dynamically.
I've been looking lately at the new JSP spec from Sun, and I'm not thrilled with the high integration of Java into the pages. Our html people are supposed to concentrate on their speciality, using html tools and such to make the pages look their best. With JSP all of our html people would also need to be java programmers (and contrary to popular opinion, the number of people who really are expert in both areas is very small. I know HTML, but I won't claim to be an expert UI designer).
For folks that are saying "Don't use Java because it's too slow" -- speed only ever increases. Ten years ago I wouldn't have said "Don't use a 286 because it's too slow." As products like Hotspot and TowerJ become popular, Java's speed increases drastically.
Disclaimer: I don't work for ATG, just for one of their customers. We're happy with their product.
PHP isn't limited to MySQL. In fact, it supports about 15 RDBMs, can talk via ODBC and access several non-relational databases. So, the question isn't about choosing a database.
Define 'real' programming language. PHP4, the successor to PHP3, is completely backwards compatible while increasing the speed of scripts and compiled binaries (not stand-alone) considerably. In fact, it's often magnitudes faster than the current PHP3.
There are discussions going on on the php developers list to make JNI accessible from within PHP. In effect, you could write your Java beans or whatever as usual and use them from PHP. That way you could take full advantage of the rapid prototyping capabilities of PHP.
Not having used either, perhaps I shouldn't comment :-)
But what I'd worry about are:
-- Does mysql handle concurrency? Remember that you may have several requests being processed at once by your web server.
-- Is PHP3 a 'real' programming language? That is, are you going to reach a point where it is not powerful or efficient enough to do what you want? When you reach this point can you easily use a third tier written in a different languiage? Note that PHP3 & a database doesn't count as three tier IMHO -- I don't think the browser is really a tier any more than a VT100 is.
Java application servers can provide a 'solution' (there's that word again) using Servlets/JSP in the first tier, Beans (or Enterprise Beans) in the second and the relational database of your choice in the third.
That second tier contains most of your 'business rules' expressed in a good programming language, the first tier handles presentation.
Compared to PHP3/mysql you've separated the programming from the presentation more cleanly, and only need one language.
I have discovered a wonderful
mySQL is way cool but does not support them.
And if you need scalability and fault tolerance, distributed transactions may be a good idea. Then you will need some kind of transaction monitor. The Java Enterprise(tm) platform offers a model for such transactions called JTS (Java Transaction Service) and the application server from BullSoft supports them.
Best regards
Ismael Ghalimi
Folks,
I think the proliferation of Java app servers, esp open-source ones, is great... but how ready are they for high-performance apps? Do any of these open source app servers support integration with HotSpot, Tower J, the IBM java hpc or for that matter, Cygnus' gcj project?
jrw