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."
I'm a little worried about java.
Its being pushed very hard by a big company.
We've been down that road a few times before.
Am I wrong to worry?
The usual reason is that you are building something more durable than a "Personal Home Page".
Java is a real, general purpose programming language. PHP code won't do you much good if you want to migrate your work to some other, non-HTML environment.
Examples: opening up your business objects for use by other people over the network; moving some of the processing to the browser; writing generic accounting software which isn't necessarily web-driven.
Java, as a general purpose language, is suitable for all this. PHP is suitable only if you are working strictly with web-based code, and promise you'll never, ever want to do anything else.
Java's also cleaner, in my experience; and allows for better project management if you have more than one team working on a project (OO benefits).
Where I work, we don't even have "problems." They're called "opportunities."
So I guess a giant asteriod on collision course with Earth is just a really big Opportunity for everyone!
Well, there are a few free "Java Assemblers" such as "Jasmin", which we used to write a compiler in Java that compiled into Bytecode.
I'd guess there are commercial ones as well, but I really don't know.
Finally, someone else who's doing this...
.92) Blackdown 1.1.7 v3, va2.2.7-1smp kernel, and JDBC (classes111.zip). We haven't started stress tests yet, but I'm curious to see what other folks are seeing in terms of performance numbers with JServ on Linux w/Apache.
- What kind of load are the Apache/JRun installs seeing? Specifically, how many max concurrent users?
- What kind of machines are the installs using (CPU and memory)?
- What kind of DB (if any) connectivity are you using (JDBC?) How many of your servlets do DB lookups?
- What version of Apache and JRun are you using?
- What JVM are you using?
- What kernel are you using?
We're using VA boxes each with 2 CPUs and 512M RAM. Redhat secure server 2.0 (Apache 1.3.3)/Apache 1.3.6 w/JRun 2.3.1 build 143 (jsp
I had really horrible experiences with Java as a server engine/db layer on Solaris (not JServ/Apache), so I'm really worried about a third party port to Linux. Basically, we ran into a ton of JVM (1.1.7) threading bugs which required on site support from Sun's JVM group. This is trying run a JVM with hundreds of concurrent HTTP users going through a web server plugin for days in a row doing db lookups.
So if Sun's JVM on Solaris was that much of a pain, I have serious doubts about the JVM on Linux, which has only recently started supporting threads and SMP.
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.
What the heck is Java Assembler? Do You hack directly in the Bytecode?
Greetz
Konrad
There is also ejboss.org and dasein.org. The former has a very active developers list and everyone is really sharp. The latter is George Reese's baby (the author of the O'Reilly JDBC book) but he's working on the second edition and so the dasein project hasn't moved for a while. Recently the two projects got together for a brief exchange on the ejboss list. George seems interested in working together with them. (P.S. I've been following gamora with great interest, and like what I see. I don't think Scott is interested in making it an EJB container, though.)
The "cue the foo posts in 3, 2, 1..." posts will commence with no subsequent foo posts in 3, 2, 1...
Java multithreads, but all the threads are running in the same process (the VM). So while all the threads are running concurrently the whole thing runs slower as the threads fight for process time. Not a big deal if you have a single CPU, no threading implementation can do anything different. But with some you can get additional performance with multiple CPUs. That is if the OS(or threading implementation) can run threads for the same process on any CPU.
I just wanted to point out that if you are running on a big enough machine and speed is still very important, you get easy concurrency with java, but it is all on one CPU.
I program in java and love it. The multithreading is SO much easier then other languages. I just really want to see a VM that can run across multiple CPUs distributing the threads. It would be really cool. :)
--
?
Thanks for pointing that out to me. I haven't looked at the how JVMs handle threading in alittle while and I guess it changed. And "green threads" does seem to spark a memory.
Didn't most of the early VMs handle their own threading? With these green threads? I seem to remember a lot of discussion about threading implementations in the various JVMs. Like Sun's Window's JVM threading versus the MS JVM's threading. I'm glad to hear the JVMs are using native threads now.
--
?
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.
My biased response is that the Locomotive is a good option.
We have been using this for a while now and are part of the development team.
It is stable, fast and easy to develop for. It also has a history of use for large sites.
In a less biased view I expect to see a fair bit of merging between the various projects over the next few years.
Regards
Dave
Did it ever occur to you that some of the largest banks are developing their backoffice systems with Java?
Java currently handles large-scale systems for Nike, FedEx, JCPenny, the Home Depot, VISA International, and several North American banks.
I think you really need to take a closer look at what is being done with Java *today*.
-Stu
I understand that you're not joking. "Silver bullet" syndrome is rampant in IT departments everywhere.
:)... This is probably a good thing, as it will hopefully pave the way for even better technologies down the road ...
However, Java is yet another attempt at bringing banks ahead in the technology curve. Smalltalk attempted to replace COBOL as the business systems language du jour - it failed, unfortunately, due to its fragmented market, inability to compete in the mainstream with C++, and a huge lack of experience in designing/building object oriented systems.
This doesn't mean that objects were useless - they're not a silver bullet obviously, but they're a good step forward in how we program systems. Java is another attempt at bringing this paradigm to the large-systems world.
I guess you can look at Java two ways: either it's another snake-oil product being peddled by the OO industry (i.e. IBM), or it's another attempt at pushing modern programming practices on the large systems of the world (which run on IBM servers... notice a trend here?)
IBM is pushing Java hard because it integrates their whole product line WHILE providing a language to effectively supercede COBOL in the long run.. (though COBOL will never cease to exist...:)
They tried doing this with Smalltalk, but failed due to the fragmented market.. that's also why a unified Java front is so important to IBM & Sun. We can't see the mistakes of yesterday repeated.
So will they succeed? With so much support & weight behind Java, it will be at least a moderate success (Smalltalk is considered a "small" success in most people's books
-Stu
When I switched to my current job, I was a Java, Perl, C-C++ programmer, mostly. Over here we use a lot of PHP3 which is rather cool. I still prefer perl cgi's, but PHP3 is quick, easy and rather dirty. Which I like.
Our next project we researched using Zope, as it seemed to be similar. As I see the two languages, I believe Zope is only for what I call dynamic HTML. It will change web pages, but if you need a large program that does a million and one things, but uses the Web as an interface, it seems to be lacking. PHP seems to be a stronger language and more powerful.
We hope to utilize Zope sometime here, but I think the reality is that it is just not powerful enough to fit our needs.
Good luck!
Its being pushed very hard by a big company.
We've been down that road a few times before.
Am I wrong to worry?
A company's great idea isn't necessarily evil just because it was originated there. What would all of us be doing if someone at AT&T Bell Labs hadn't thought "Hej, Brian, why don't you go check this MULTICS thing out?"? Hm...
At the end of the day, there is no Open Source object-oriented, portable, widely available programming language that has the same acceptance of Java. C++ is too complicated and doesn't enforce the OO paradigm well. Smalltalk? Too fragmented, though I'd much rather program in it than in Java if it were as widely available. PERL and Python are great, but so-so for OO (besides, if I wanted a language that resembles my other 10 favourite ones I'd program in Ada). That leaves Tcl... which could be a good option, but it also originated at The Big Company and hasn't had as much acceptance as Java.
(Before the flames start, I should let you know that I've been programming in C since 1984, C++ since late 1988, Smalltalk since 1990, assembler since 1983 and that I've delivered many products under all those languages including Java running on all kinds of hardware, from embedded to mainframes. So I'm not shy about using these tools when they make sense. In fact, we're currently developing a Big Project mostly in Java assembler because it makes business and technology sense)
Like UNIX and C, Java will probably grow out of Sun's tight control at some point in the future. Transvirtual is walking that path, and so are a few of us who want to separate good ideas from politics and make some money in the process.
Cheers!
Eugenehttp://eugeneciurana.com | http://ciurana.eu
Python seems to suffer the same problem as C++ when it comes to OO: It supports it but doesn't enforce it very strenously. Java is somewhat better, but you can still do Stoopid Things like defining pseudo-global public variables. Also, these languages support primitive types, which tend to be a no-no because they violate OO concepts by letting people write code that deals with them even in high-level objects.
I have nothing against Python as a language; I actually like it quite well compared to PERL. My point was OO and availability, not technical elegance. From this latter point of view, Python rocks!
Cheers!
Eugenehttp://eugeneciurana.com | http://ciurana.eu
The downside at the moment is that, because Zope's fore-runner was an internal product used by Digital Creations, the DC people didn't have a lot of documentation for it. They've been working on getting more docs written, but the picture is still somewhat scattered. If you end up reading the source code, it would be difficult for a Python newbie because the code so full of cutting-edge technique. Luckily, you can do a lot without having to dive into the source code; it only matters for more complicated things like writing a new product or DTML tag for it.
While you're at it, check out Squishdot, which is still in really early alpha; it'll be astoundingly cool when it's finished.
OK, here's the scoop. I *DO* servlet programming for a living. We've pulled together webmacro, IBM WebSphere AppServer and MySQL on Linux. But if I had a choice, I wouldn't be using IBM WebSphere. We got lucky, and didn't have to pay for it. It's mostly fast, and does everything we need it to - for now. But it's got it's flaws, and it's a resource pig - 30Meg of Memory to run two servlets? And It's the only app I've seen to Max out CPU Utilization on Linux. Hell, it's the only thing I've seen *KILL* apache deader than a doornail. We're still looking at the OpenSource Servers because they look smaller, faster, and just as feature rich. Please Tell me which one you choose, and why. I want to take it to my boss as an alternative.
--- Kevin "The Alchemist" Sonney --- --- http://www.darkcanvas.com/~alchemist ---
So, is the term Application Server just some sort of marketing slang?
I've gone from developing CGI in a variety of languages to Java Servlets, both with tight integration to a DBMS, and including such features as load banancing, connection pooling...etc...etc. Since I stay mostly with Open Source software, I haven't come across the term 'Application Server' very often. What does the combination of existing technologies lack that an Application Server provides?
Is it somewhat analagous to building a linux based workgroup server from an old PC, or going out to buy a Cobalt Qube (or similar product) in that to obtain a particular functionality, one you have to put together yourself from surplus parts and free software, and the other is a turnkey solution?
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
I recommend you confine the 'app server' to:
1. managing state between http requests
2. connecting legacy stuff to HTTP responses
3. mapping HTTP requests into a transaction space.
If you can architect thusly, you can use this recipe:
apache
mod_jserv
mod_php, mod_perl, etc.
mySQL
gnuJSP
jWebForm
And remember, none of the above are mutually exclusive. Don't pay enterprise-class java grinders to hack html, and vice-versa.
How can they feel the rain but not know of the flood?
Please check the facts about Oracle Application Server before you state that 'it was so good that Oracle stopped using it for their own site'.
A simple HEAD request to www.oracle.com gives:
HEAD http://www.oracle.com/ HTTP/1.0
HTTP/1.0 200 OK
Date: Sat, 03 Jul 1999 00:20:07 GMT
Allow: GET, HEAD
Server: Oracle_Web_Listener/4.0.7.1.0EnterpriseEdition
--
The company I work for used Enhydra to deploy a WWW e-commerce solution, when it was Lutris Business Server. The problems we have had were based around Java (Sun JDK). The consensus is that Java 2.0 is required if any stability is required. I wrote the database layer we use, on top of Jconnect from Sybase. I also spent a lot of time babysitting the system. Since the Java 2.0 upgrade it seems to be very solid and the performance acceptable. As far as the architecture of Enhydra/LBS goes, I thought it to be fairly good. The major issues I had were the lack of a good procedural database API library and a good email library. The implementation of an email sender uses command line Sendmail rather than a Java based SMTP client. The server Java stuff isn't a blazing whack of speed, but it's decent. After having used server side Java, my opinions have greatly changed. I personally think you're better off using Perl, especially if you use mod_perl. YMMV
These products seem to be 'pure' Java (ie they use no non-standard native code). That means you can run them on any compliant runtime you like. HotSpot and GCJ ain't finished yet, but when they are you can just use them.
Hi there,
:)
I'd suggest anyone interested in web application servers also take a look at Zope:
http://www.zope.org
It's not in Java but in Python. It is open source, very dynamic, uses some wonderful design ideas that really make life easier, and has a very nice user community. New features are being created at a rapid pace.
Some random hype:
* Manage it through the web! You can manage almost all of Zope through a web interface. No clients are needed, no server access other than web access is needed.
* object database; publish objects, not files, to the web. Objects can have properties and can talk to each other.
* acquisition; a concept somewhat like inheritance that has very powerful implications. (we have inheritance too; acquisition is inheritance around another axis, so to speak, so they are complement each other)
* Very configurable security system.
* If you don't know Python yet; a wonderfully clean, powerful, flexible, object oriented interpreted language.
* Zope is continuously being developed by Digital Creations, who are very responsive to the user/developer community. Open source not just in name, but done right.
* Okay, so I like it.
Regards,
Martijn
For more information, go to the Jakarta web site.
- Sam Ruby
"E*Trade is all Java (v1.1.x) running on top of Netscape App Server (formerly Kiva)."
I've used NAS. It sucks. Terrible API. Inflexible. Lousy performance. You'd be better off writing your own from scratch.
"Cars.com is all Servlets and JDBC."
And they have serious problems because of it. I've seen their design and it's not very scalable.
There's nothing magic about JavaBeans. You can program a perfectly good, scalable app using simpler stuff like Gnu Server Pages from http://www.bitmechanic.com/. This won't prevent you from using JavaBeans, but it won't force you to use a certain methodology for your development, and I like that.
You should also keep in mind that Java on Linux is dog slow and probably will be for a while. Java is solid on Solaris and NT, but Perl is currently in better shape on Linux, IMHO.
"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's completely untrue. I've used Netscape's "application server" and it's just junk. We were running on big Sun hardware with the latest optimized JVM, and it still didn't perform well or reliably. The clustering features are no replacement for a load-balancer in front of the webservers, and it's not difficult to share session/state information between machines using a database. There is no reason to buy this stuff. Just use the good open source stuff (mod_jserv, mod_perl, PHP) as a base and write your app on top of it. Most people end up hacking lots of stuff onto these app servers anyway to get them to work.
Jakarta is just the code name for what the jserv community is becoming - the repository and reference implementors of the Servlet specs.
Same developers, same codebase, merging the Sun code with the jserv code to create a killer engine.
Not to nitpick, but Tcl & Tk originated at UC Berkeley (GO BEARS!). Dr. John Ousterhout was the man behind it.
Scuttlemonkey is a troll
Java Server Pages (JSP) has been recommended in a few posts. Although JSP has some good things going for it -- open specification vs. proprietary markup, easy integration with Java objects, Beans, standard and 3rd party Java APIs -- it also has some serious problems. The main problem is that JSP is a clone of ASP a 3(?) year old technology.
JSP, ASP, and Cold Fusion, they're all the same model. Your content is managed in files. Those same files also manage your code. I'm aware each platform has facilities for marshalling external objects. And I'll even pretend that everyone in your orginization is going to be good and code business rules in seperate objects. Even then, you're still mixing presentation with logic. Worse, you're managing content with files, unless you have a handfull of master, super dynamic templates that don't even dictate presentation. But then, you're implementing a content management engine that could be more easily written as a Java Servlet or your own app server.
There are some alternatives to using middle-webbish (ASP, JSP, CFML) for dynamic content:
A group at java.apache.org are working on the Server Pages Foundation Classes. One of the problems they address is the loose coupling between "templates" when you're developing a workflow that takes place accross many screens (like account creation, shopping cart, etc.).
Also at java.apache.org is Cocoon, a Java Servlet (or standalone Java app) that use XML and XTL (XSL:T) to serve pages where content is seperate from presentation.
More on the XML front -- which is, IMO, the current best approach to develop highly dynamic, content driven sites -- IBM Alphaworks has a lot of XML tools available. The two I've found the most usefull are xml4j and lotus XSL. The source is available for both, but I haven't reviewed the licenses. No matter, other OS XML projects -- like Cocoon --- are capable of utilizing the commercial APIs by defining their own API, then implementing wrappers around IBM's classes.
And there's many more...these are just the ones I know enough about to comment on. The reality is, middle webbish is proving insufficient. This has produced an area bubbling with ideas and new approaches to developing and managing dynamic Web sites.
ASP is 3 years old. It and it's clones have enabled the Web to grow, but those technologies are bursting at the seams. XML is new, perhaps too new, and it's debatable if XTL (XSL:T) will catch on. But one thing is certain to me: XML is where it's at.
Is this a troll? Be realistic. The Java language and the Java VM specs are both available. Anyone can implement a clean room VM and core API and compete. A few people have. The Open Source community can decided at any time it doesn't want to pay Sun, IBM, Symantec, etc. for Java VMs and implement an OS alternative. That's what Kaffe is. The reality is, so far commercial entities have been able to implement complete, fast Java VMs and the Open Source community hasn't. I'm not trying to belittle the efforts of Kaffe. Just that OS projects usually have a long ramp up time before the Bazaar starts to take effect. The point is, Sun has presented no insurmountable barriers to developing an Open Source Java. I think there's been low interest in an OS Java because Sun, relative to the rest of the commercial industry, has acted in a manner cooperative with the OS industry.
I've been using a proprietary Java app server for about a year now (Dynamo from Art Technology Group), and I've had mixed luck with it. It supports a bunch of useful web-oriented stuff quite well, but it's overly complex, and the proprietary nature has caused a lot of problems.
As I've looked around for other possibilities (Open Source preferred, proprietary considered), I've started to ask the question above: what exactly do we expect an App Server to do?
If you read the marketing materials and press releases, all app servers seem to do everything. However, my sense is that each product is trying to solve one particular problem, and, if you get something which doesn't solve your problem, it's going to be painful to use (at best).
For example, for the database-backed, community-oriented site (like this one, say), what do you need from an app server?
My personal vote:
- Fast but flexible HTML templating
- Database Connection Pooling
- Possibly, session management (possibly not)
What else? From my experiences with Dynamo, I feel very strongly that you want your app server to support close to the minimal feature set you need, because that will make it simpler, which will make it stable (and easier to use, and all sorts of other good things).
For commerce, you'd need some other things. I haven't built a commerce site. What other things would those be, anyone who has?
Sometimes I think having an App Server for a database-backed web site is setting up a big, complex piece of technology simply to get around the CGI process-spawning performance hit. This seems to me like a Bad Idea, which is why I'm wondering:
What are we looking for from an app server?
Incidentally, this site, which was written by a small group (of how many?), serves an incredible number of pages, supports all kinds of collaborative trafficking of information, and is just in general an example of what The Web Should Be, doesn't have an app server at all -- unless you consider Apache and mod_perl to be an app server, which I'd be perfectly willing to do.
I have written a truly remarkable operating system which this sig is too small to contain.
I use Java servlets combined with Apache JServ on Apache connecting to mySQL. It's great!! It's really fast. Hopefully the Linux HotSpot stuff will be done soon, along with Java1.2 support in JServ...
RateVegas.com - Vegas Reviews
I'll drink to this... Too bad you can't deploy WebObjects on Linux yet... Solaris, NT, MacOS X, HP-UX only... Still, a great platform!!
Just gotta get rid of the Objctive-C zealots...
RateVegas.com - Vegas Reviews
Why not try WebObjects. It is the best App server out there and you can write the whole thing in Java if you want to.
Runs on Solaris, HP-UX, NT and MacOS X
Maybe you shouldn't.
On the other hand, if you're interested in a language that actually enforces object integrity and type safety, maybe you should give Java (or half a dozen other OO languages) a look.
And if you're interested in finding a DB which supports foreign keys or rollbacks, maybe you should look beyond MySQL too.
Don't get me wrong: I use both PHP and MySQL nearly to the exclusion of everything else. But that's just because it happens to be suitable to everything I need to do. Remember the adage, "When all you have is a hammer, everything starts to look like a nail." Well, when all you have are nails, you start to wonder why you'd need anything that isn't a hammer.
High Performance Java:
+ E*Trade is all Java (v1.1.x) running on top of Netscape App Server (formerly Kiva).
+ Cars.com is all Servlets and JDBC.
+ I have personally load tested a single Sun UE2 (2x300MHz) running Java Web Server and Servlets (with db access) up to 315,000 transactions/hour. This was done with JDK 1.2b3.
+ There are many others....
HotSpot:
+ HotSpot is a replacement VM, not a compiler. I spoke with some of the guys from the development team, and they are very near 100% Java2 compatability. If something uses a Java2 VM, you will be able to replace it with HotSpot.
TowerJ:
+ I have first-hand knowledge of a large European auto company using TowerJ to compile a client-side Java(CORBA) application. It worked as intended, and sped things up quite a bit.
So there you go,
jason
What are the 'serious problems' that Cars.com has as a result of using Servlets? A few months back they switched from using the JWS to using NES as the web server, but that's the only change I've seen lately. Was that the problem? Also, how was the architecture not scalable?
I'm not defending NAS, per se, but the fact is ETrade get boatloads of traffic, and they handle it reasonably well.
I don't suppose you've single-handedly built an app server and run a site on it that gets in excess of 10M hits/day, have you? How'd you do it?
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.
Can someone with real-world experience with both application servers and more standard technologies (CGI, Perl, JSP, servlets, etc.) compare what advantages app servers and/or EJB really bring to the table? I am developing my first app server project now (Enhydra), and see some definite advantages, but not a huge number of them, at least for now.
BTW, please don't mention MySQL, or database comparisons... the database backend doesn't matter in the discussion of app servers/EJB vs not.
----------
In a real emergency, we would have all fled in terror, and you would not have been notified.
If you aren't stuck on the idea of having an open source product, I've also found that WebSphere is pretty good, although I haven't really given it the once over in Linux yet (just installed the beta yesterday).
We did some speed comparisons a month or so ago comparing various servlet engines under Solaris. Using Netscape's incredibly slow java engine as
a baseline, we found that ServletExec, and JRun
provided about 3 times the performance and WebSphere gave about 5 times the performance (if I recall correctly). Apache was not a possible webserver choice for this experiment though, so I didn't get to see how JServ would handle the test.
Hope that's of some help!
---
This sig has been temporarily disconnected or is no longer in service
call the classes and get the information out of them.
---
This sig has been temporarily disconnected or is no longer in service
Locomotive
Protomatter
Enhydra
this space intentionally left blank (oops)
How about widening the box for /. posts? (Or telling newbies they don't have to hit return overly much?)
-B
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.
Actually, you can use Apache JServ as the servlet runner to operate Enhydra under. If used in this configuration, Enhydra offers extensions and additions to what you would normally have with plain servlets. You might want to look at this for some info on why a few people have chosen to stick with Enhydra. BTW, if you don't have JServ (or a web server for that matter) you can run Enhydra apps directly with the built in web server functionality.
- 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.Can someone explain to me why an appserver is more scalable than a solution like mod_perl. Providing I code my application to maintain no state on the web servers, I can just keep adding web servers if I run out of horsepower. Eventually the bottleneck becomes the database. Isn't the same thing true for app servers. You keep adding more of them and eventually the database becomes the bottleneck? Just seems a more complicated way of getting to the same answer.
Alexium - open source software and articles for web publishers
Here is my number one reason why Java is the right way to go for server apps. Unless you use OS hooks and kludges and the like, there is no equivalent in C/C++. (Perl is a different ballgame, and here I'm making the assumption that top speed is critical.)
// Tell programmer to be more careful...
String stringToPrint;
void saySomethingNifty() {
httpWriter.println(stringToPrint);
}
void doSomethingButForgiveStupidProgrammer() {
try {
saySomethingNifty();
} catch (Throwable t) {
}
}
Do you see how great that code is? If the programmer accidentally references a null pointer, runs out of memory, or even deletes a class file by accident, there is still an elegant way to recover. Of course this is oversimplified, but now that I have written a server app in Java I can't imagine how the same stability could ever be achieved with C/C++. When I add new code and it generates a NullPointerException, a very minimal disruption of service occurs. I've even found ways to recover from infinite loops.
Well there's Obj-C. If only GNUStep were complete, it's the only OO programming environment you would ever want.
I think the trick here that Netscape uses is that the most important libaries: Database, templating, i/o, caching, etc, are all written in c++. Also, we are using a JIT compiler, and the classes are cached between sessions.
Now, if only there were a open source version of this. All the speed of native, and yet I can code in Java!
-- these are only opinions and they might not be mine.
I'm using Apache JServ with great success (or should I say that it's the most stable, most problem-free piece so far). I think that it's termed more of a 'servlet engine' than an 'application server' but I'm not crystal clear on the differeneces anyway. Speed has not been an issue AT ALL - it generates and serves some dynamic pages faster than similar static ones elsewhere on our intranet. The servlet solutions take a hit on the first instantiaion, but are blazing fast thereafter.
In our environ, it's part of a 3-tier (or is it 4?) system (apache-jserv-openlink middleware-ms sql & db2) that's in partial production. The earlier beta version were a b*tch to configure and get active, but are very stable once you do. I'll be trying out the 1.0 versions this week.
Feel free to email questions.
I've done some fairly extensive research into many of the commercial players (Apple WebObjects, ATG Dynamo, BEA WebLogic, Bluestone Sapphire/Web, Gemstone/J, IBM WebSphere, Persistence PowerTier, Sun NetDynamics, Sybase EA Server) with a focus on their viability as a platform for Java development and here are a few (perhaps not very insightful) thoughts:
0. What is an "application server"? The way that I've come to use the term is a middlware product that provides a development framework; addresses functionality like failover/redundancy, database connectivity and connection pooling, and state and session management; provides reporting and management tools and generally a development tools and wizards. That's pretty generic and different people definitely us the term to mean different things.
1. There aren't any astoundingly bad products in the bunch, though some are obviously better than others.
2. They've got different strengths so there isn't a single product that is best for everyone in every situation. (Examples to follow)
3. They are also all quite pricy. 10K-30K/CPU + 2K-10K/developer seat tends to be the range.
My observations about some of the specific products:
1. WebObjects has a very complete, well-thought out development environment, however, its Java support is somewhat incomplete (e.g, no EJB support) and it pretty much restricts you to doing development under NT. I also have reservations about whether Apple, much as I love it, is serious about and capable of playing in the enterprise computing market. It's certainly a proven technology, though somewhat proprietary. Good for RAD development, if you don't have to worry about migrating an existing code base or about potentially migrating to another platform later on.
2. Dynamo is probably best suited if you're interested in using their whole suite of products (personalization, ad serving, etc.). It's really only suited for web sites, so if you are looking for a more generic middleware product for non-web applications, it's not a good fit. It does have reasonably good support of Java standards. Since they are a smaller company, as the app server market consolidates they might get squeezed out or acquired.
3. WebLogic is the product that was the best fit for us. A pure Java product with the most complete support for Java standards, including a comparatively robust EJB implementation. It doesn't come with a development environment although it does have some nice hooks into third-party IDEs and a nice EJB wizard. Whether you prefer this approach to the included IDE route is pretty subjective.
4. Sapphire/Web has an elegant, robust architecture and has the added benefit of also being an XML server. Java support is pretty complete. I really didn't like their development environment or the way that pregenerated code and custom code live together. Same concerns about market consolidation.
5. I didn't get a very good feel for Gemstone/J although it seems to be most similar to Sapphire/Web. Fairly complete Java support, some oddities in actual development. Those familiar (and happy) with their SmallTalk product might want to go with this.
6. WebSphere seems very much like a work in progress. IBM is certainly making progress, but it still feels incomplete. I really can't recommend it yet, but it's worth keeping an eye on. It inherits IBM's heavy Java focus.
7. PowerTier is another product that I don't have as much of a feel for. Pretty complete Java support and with some interesting database stuff going on. It's not a Java product itself though, for better and worse.
8. I looked at NetDynamics a generation back and it seemed to be distinctly behind the curve in Java support - ironic, huh? They seem to have made strides towards addressing that, but I don't think anyone really knows what's going to happen with NetDynamics and Netscape Application Server now that Sun owns them both. I'd be inclined to stay away from both until the picture becomes more clear.
9. Sybase EA is much improved from it's earlier incarnation (Jaguar), but it about a generation away. Probably a good fit for shops looking to go Sybase across all tiers.
A bit of background - perhaps this should have gone at the beginning - I've used PHP fairly extensively and while I like it as a product, it doesn't really provide the facilities for stateful sessions which is important to the work we do. For the last year we've been using servlets+JServ and a custom built Java app server, with the servlets talking to the app server via RMI. For those following along at home, building an app server is a serious undertaking...
JServ is a nice servlet engine as are commercial competitors like JRun and ServletExpress. If you're just looking to do servlet work, this should be fine. If you're looking to build EJBs and server side Java objects beyond servlets, you'll want something more.
I should also point out that there are obviously lots of other languages that work perfectly well for building database driven, dynamic content sites.
Finally a couple thoughts on EJBs - It's worth noting that EJBs in general are very much a work in progress, so it behooves you to know the issues before selecting them as a development route. It is really a different way of doing things. Tools for EJB development aren't very mature. Also, entity EJBs really don't span multiple tables well and stored procedures are basically out of the picture if you use container managed beans. So, it means that you lose database transparency and distribution of load, both of which are good things in my mind. There are some products in the works to address this (e.g., TopLink for WebLogic), but this is a very new market. Don't work on the cutting edge if you aren't willing to lose some blood...
Finally run out of things to say. Hope this helps...
Their product is really very nice, but a little expensive (like $10K). If you're doing enterprise Java work, it's great though. It supports (or plans to support in the near future) all the "enterprise" java APIs and services.
-nate
"Unlike JSPs it's Open Source" ?? What are you talking about?
JSP is a spec, not a product, and furthermore, JavaSoft/Sun has formed an alliance with the Apache people so that the default JSP implementation will be available under the Apache license...
-nate
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
I have built a java middle tier as well as an
applet front-end for connecting to a mSQL database. In my experience the middle tier has
been plenty fast enough. As for the applet front
end, yes it's a bit slow to load in the beginning,
but once it's loaded it's more than capable of keeping up with user input.
AFAIK Jakarta hasn't been started yet - they are still waiting for the reference code from Sun.
However, the Java Apache project is going strong, the final build of JServ (a servlet engine) was released recently, along with mod_jserv (Apache hooks to JServ).
They also have produced Cocoon, which is a XML transformation engine, and rather good too. Version 1 is just a proof of concept but still works well, version 2 which is being designed now looks like it will be amazing, the groundwork going into it is amazing.
well...i'd like to keep my logic separated from presentation. php actually seems (havent used it) to be really cool from what little i know but im not sure if it has advanced features like pooling which are generally needed if you want to scale well
p.s. sorry for the fscked up links, coulda wsore i did them correctly
-- your knees hurt, don't they?
sorry, i'll try to be more politically correct next time.
-- your knees hurt, don't they?
Just FYI, Apple's WebObjects won the Java Developer's Journal Reader's Choice Award for Best Application Server. Definitely worth a look.
None of known to me data processing application works on a "naked" hardware, so even if we assume that Java is not used for a middle tier application, but for a deeper digging "100% Java" application server, it still stands on a very high foundation of a native code. A typical data-application server will spend most of it's time waiting for IO completion here and there and not cranching what it retrieved from disks. Why do you think all those PL/SQL at al applications survived and even prosperred?
One may argue that Java based app.server will create more load on a processor that native-code compiled application. While to some extent this is true, the difference is not that significant with a JIT, when Java can come a little closer to the hardware. On the other hand, despite all the deficiencies in the language itself that can only be abhored (like elimination of multiple inheritance, inability to overload operators, absence of templates - IMHO the last one is particularly painfull) it still provides today unmatched environment for programmer productivity with it's garbage collection and extensive standard library.
The only visible prblem today for Java based app.servers - besides those mentioned above language constraints - is memory consumption, which is quite significant. But again, a typical hardware for app.servers today has more than 64M of RAM (you have to run your database somehow and it loves to cache pages), so it's usually not a real problem.
In my carrier as a software engineer I have been involved in several quite large projects that targeted application servers. Some of them where written in C++, and some, more recent, in Java. We never experienced performance problems with Java servers, but it's worth to mention that our development productivity has increased and noticeably.
One more comment - about "green" threads JVM: though the entire process is executed by a single CPU, provided properly implemented, JVM should be able to let threads run when one/several of them are waiting on IO completion. It would take careful design with non-blocking I/O, but it's doable, and I would guess that Sun's green-thread JVM uses something like that.
I think that I see your problem. I had assumed that you were working with applets and that's why you were complaining about speed. In reality, its probably just your expectations.
In an NT world you are using at least 32 MB just for the operating system. Add another 16 for application server overhead, and another 16MB for web server overhead and caching, and that means that you are going to be paging to disk constantly even with low system usage. Assuming ten thousand concurrent users, you have just 6.4 KB per user, not even counting the overhead.
Yes, an Apache/mod_perl system will run better under these kinds of conditions. Linux has a much leaner footprint, and Apache can be tweaked for low memory footprints.
On the other hand, if you are going to be paying six figures for application server software (Tengah, now called WebLogic after being bought out by BEA, isn't cheap) why don't you invest some money in hardware? Most application servers require at least 128MB per processor and most recommend a quarter gig to a half gig per processor. (Application servers tend to be much more memory intensive than CPU intensive. I've even seen some systems perform much better with 1GB per processor.) You can get 128MB SIMMS for $300-$400 these days.
The bottom line being: if you have an existing low-end piece of hardware that you need to get the most bang for your buck from, you should be looking at PHP or something similar. If you are looking for something that is scalable to tens of thousands of concurrent users, and is easy to develop and maintain, you should be looking at Java application servers. But if you do, you should expect to have to scale your hardware appropriately.
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 just putting this out as a choice and am not going to give any opinions. I have not personally used it.
SCO Tarantella
---- "It is never too late to give up our prejudices." --Henry David Thoreau(1817-1862)
In your place, I would reconsider whether you really schould use a Java-based solution, solely for the reason of speed. (In fact, I see many other problems in Java, but speed is what websites are about).
We have seen a lot of benchmarks for Webservers and it is a tight race. Using a RDBMS written in native code reduces response times, but its a database you want and these are the fastest you get.
I have programmed Java for half a year in an internship, hab a pII/300 and 256Megs of Ram, and it was only just bearable. Imaginig some Java-based huge Database-backend to a highly frequented site is nothing I can imagine.
No 'solution' using Java (be it as a means of Data Storage or even a highly used servlet) would be able of the figures that, say Apache and mySQL give you. I actually believe that you would need a really really big machine to manage this for a site that would be fine with some Cobalt RAQ and mySQL.
Ben
There are two Apache/Java integration projects that I know about; one was already mentioned, the Jakarta project (jakarta.apache.org), "dedicated to providing a high quality, world class 100% Pure Java Servlet and JavaServer Pages implementation", and the Java Apache project (java.apache.org), which has a JVM built in to the Apache daemon, and inlcudes JSSI and full servlet support.
Though I haven't personally used either of these creations, I do know people who have had great success with the Java Apache modules. This project includes mod_java (similar in function to mod_perl or mod_php), client applications, and a document publishing framework as well as server extensions, so for a large scale solution, this may be worth checking out.
Also, I believe, the Java Apache project is more mature than the Jakarta project (although I may be mistaken about this).
darren(darren)
I've built lots of big systems in PHP, and earned a considerable amount of living doing it; so I'm really grateful to Rasmus and his team. However, I'm gradually moving all my systems away from PHP now, over to Java servlets.
Why?
Well, first is engineering. PHP is a neat hacky tool which does what it does very well. But it's not a well thought out general purpose programming language (it's not meant to be). And unless used in it's guise as an Apache module it's highly inefficient. Although I use Apache on all my servers, many of my customers don't.
Also, PHP versioning is a real problem -- it's very difficult to convert things written for PHP2 to PHP3, and PHP2 as distributed does not work with Apache 1.3 as distributed.
Whereas Java is a really elgant language which I use for most of my non-Web based stuff, and it's reasonably efficient, and the Servlets I write to plug into my Apache server will plug just as easily into my customers' Sun and Netscape servers, and even run on (hiss) (spit) NT without recompilation.
I'm old enough to remember when discussions on Slashdot were well informed.
Could someone please fix the URLs for proper clicking? (Then delete this post)
FunOne
FunOne
I too am looking for a Java app server... we're leaning towards WebLogic, though we haven't ruled out Sapphire. However, my boss came to me on Friday and said, "you know, we're a MCSP and have lots of $$$ invested in MS training and blah blah blah so you better give us all a good explanation as to why you're risking our largest contract on Java technology...." He has somewhat of a point, given that we are mandated to run on NT.... however, the DNA architecture is a load of unreliable, unscalable, stateless, single-threaded garbage, IMHO. But, I still have to drill down on the MS BS with him... does anyone have their reasons for using a Java app server over the DNA architecture?
I think I've got a good case, but I need more fuel, lest I end up sleeping with VB books for the next few months.
-MVK
Actually, most compilers do/will not support dynamic loading of classes. I'm not certain that you can't work around this restriction, but I'd caution against just assuming that these compilers will work with, say, EJBs out of the box.
I'm pretty sure they won't actually. EJB containers automatically generate wrapper classes at "deployment" time. These classes are created after you've compiled your app, and thus the app won't be able to use 'em.
You can work up a fix for this fairly easily, I'd imagine, but still it needs fixing, I think.
Johan
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
Can we put a lid on the elitism at least when we're answering Ask Slashdots?
grep -ri 'should work'
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.
It's not Java, but in our current project we've found the Perl system Mason (available from CPAN as HTML::Mason) to be very good. There are a couple of annoying bugs, but supports a scalable rapid prototyping model better than anything else I've seen.
Aside: The project we're working on is a University intranet/extranet, designed to support about 40,000 users across two continents. All pages are dynamically generated, written in Perl with Oracle and LDAP helpers. HTML::Mason handles the task extremely well on sufficiently grunty hardware.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
If you don't want to mix up HTML and PHP, use FastTemplates. I've written some apps for clients using that thing, it completely seperates code from HTML. The average size of these apps is about 10000 lines (wc -l) of PHP code. Maintaining and enhancing it would be a nightmare, if I would have to deal with the designer's HTML stuff.
FastTemplate Tutorial
And yes, of course, PHP is not the right tool for every job. The same is true for Java.
Try Zope.
Then try PHP.
You won't want to revert to Zope.
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.
Bull's EJB server is easy to set up and works well, as far as I can tell from the limited experience I've had with it. It seems to be significantly faster than EJBHome, for instance.
But perhaps I missed your point?
I have discovered a wonderful
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
Even though IBM WebSphere is commercial you might want to look at it's features to see what one can do with a Web Application Server. You might also compare IBM WebSphere with simply a webserver that supports servlets. Keep in mind how large your application may grow. While things like simplicity, reusability, security, and good performance are very important pick a architecture that allows your app to be extensible as well.
A blip from the IBM web site:
IBM WebSphere(TM) Application Server is a Java(TM)-based application environment for building, deploying and managing Internet and intranet Web applications. This complete set of products expands to fit your Web application server needs, ranging from the simple to the advanced to the enterprise level.
http://www.software.ibm.com/webservers/
Enhydra is very cool. It's getting a real user community and it's improving very fast. The XMLC compiler allows a real separation of work done by designers and programmers.
By the way, Bull is open-sourcing it's EJB application server. It supports Enterprise JavaBeans(tm) and transactions.
Best regards
Ismael Ghalimi
ghalimi@exoffice.com
http://www.openmaster.com/ejb
Just after having posted my first comment on
The code will be made available under an MPL-like license by one or two weeks.
Regards
Ismael Ghalimi
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
Php and Zope are two different sort of things. I would call Zope an application server. I wouldn't call PHP an application server, although you can do a lot of the same things with it.
I use PHP, and I am looking at using Zope, and I can see places where both have strengths. In a lot of ways, it is a difference between some sort of templating system/server-side scripting system (Php, Perl-with-your-favorite-modules, SSI, etc.) vs. an integrated serving package like Zope.
Whether you prefer the former or the latter I would think depends on a) how much you enjoy programming and b) whether the content development is being done by one person, or is heavily distributed. Packages like Zope tend to insulate you from coding (at least until you need to go beyond the basic packages), and are usually built to facilitate heavily distributed content management.
Well writen tool-man. Thinking that Apache-perl -mySql is the only solution is just dumb fanatism.
---> Did you know Linux stands for Linux Is Not UniX ?
I have used this on Solaris and also on NT, and I like it. Look closely at the design, JServ could be used to make REALLY big sites. Multiple JVM's, context separation, Many Web server to Many JVM's, load balancing...
I was under the impression that ETrade ran on BEA's TUXEDO, and TUXEDO does not support anything other than C, C++ or COBOL (yeech!) for server side applications. Yes you can write TUXEDO clients in Java using Jolt, which is horrid.
Are you talking about E*Trade's web interface or their trading engine or both (it wouldn't surprise me if the web interface is nice Java, while the trading engine is cold-hard C or COBOL in TUXEDO!).
The unfortunate thing is... it is very hard to convince people that Java is ready for enterprise OLTP... I'm not convinced myself! We're writing a product using TUXEDO / C and embedded SQL, I would dearly love to write it in Java, but until someone can prove that it won't run like a dog (or at least, not run so slow that the hardware upgrades bankrupt our customers!) AND it will sensibly support XA/2pc (ob this is the responsibility of the Java app server) then we have to stay with the tried and true proven technology!
Egads!
jrw
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