Ask Slashdot: Which Java Applications Server? 168
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."
java? really, why? (Score:1)
Its being pushed very hard by a big company.
We've been down that road a few times before.
Am I wrong to worry?
Re:PHP3 && mysql (Score:1)
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).
Re:Solutions?!? (Score:1)
So I guess a giant asteriod on collision course with Earth is just a really big Opportunity for everyone!
Re:Java Assembler? (Score:1)
I'd guess there are commercial ones as well, but I really don't know.
Does Apache/JRun scale? (Score:1)
- 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.
Re:links that will work: (Score:2)
Re:PHP3 && mysql (Score:2)
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.
Re:Apache JServ! (Score:2)
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.
Java Assembler? (Score:1)
What the heck is Java Assembler? Do You hack directly in the Bytecode?
Greetz
Konrad
Re:Free EJB Servers (Score:1)
Re:Speed? (Score: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. :)
--
green threads in early VMs (Score:1)
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.
--
Enhydra (Score:2)
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.
Re:PHP3 & mysql (Score:2)
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.
Java is fast enough, with the right VM... (Score:2)
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.
Biased Response (Score:1)
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
Hmmmmmmmm (Score:1)
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*.
not joking (Score:1)
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
Re:Java, PHP3, Zope (Score:1)
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!
No more politics, please! [Re:java? really, why?] (Score:1)
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!
EugeneRe:No more politics, please! [Re:java? really, why (Score:1)
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!
EugeneRe:Java Assembler? (Score:2)
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!
EugeneRe:What about Zope? (Score:1)
The downside at the moment is that, because Zope's fore-runner was an internal product used by Digital Creations [digicool.com], 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 [tripod.com], which is still in really early alpha; it'll be astoundingly cool when it's finished.
After working on a large App Server Project... (Score:1)
Dumb Question? (Application Servers vs Everything) (Score:1)
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?
Free EJB Servers (Score:2)
The URI is http://gamora.org [gamora.org]
From the Gamora readme [gamora.org]:
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
3 Free Servers (Score:2)
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.
GPLd Java/Web app server (Score:1)
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 [techplace.net]
And remember, none of the above are mutually exclusive. Don't pay enterprise-class java grinders to hack html, and vice-versa.
Re:A word about application servers (Score:1)
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
Enhydra (Score:1)
Re:HotSpot / Tower J / etc support for Java App Sr (Score:1)
Not Java, but very cool: Zope (Score:1)
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
Try Apache's Jakarta (Score:2)
For more information, go to the Jakarta web site [apache.org].
Re:HotSpot / Tower J / etc support for Java App Sr (Score:1)
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.
3-tier? Why? (Score:1)
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.
Re:Speed? (Score:1)
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.
Re:Java/Apache - Jakarta *is* JServ (Score:1)
Same developers, same codebase, merging the Sun code with the jserv code to create a killer engine.
Re:No more politics, please! [Re:java? really, why (Score:1)
BEWARE JSP: there be dragons in there (Score:1)
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 [apache.org]. 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 [apache.org], 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 [ibm.com] has a lot of XML tools available. The two I've found the most usefull are xml4j [ibm.com] and lotus XSL [ibm.com]. 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.
Re:java has not been freed (Score:1)
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.
Re:BEWARE JSP: there be dragons in there (Score:1)
True, LotusXSL is slow. The documentation even says the focus was on completeness and stability. Funny, that's how Apache started...but I'll leave that alone. There's other XSL processors available. But taken as a whole, XSL is very, very bleeding edge. So what is an early adopter to do?
Unless your pages are changing constantly, use a caching mechanism. If your site is very static, only generated dynamically occasionally, then spider your site. Otherwise, reverse proxies like SQUID do nicely
Let's say your pages do change every second, or your pages are personalized to such a degree (like slashboxes) that only just in time creation works. You could:
My preference is to use XSL, or more acurately, XSL:T or XTL or whatever the part of XSL that just deals with tranformations. However, the more important part is getting your content represented as XML. That's the most important. Here, this person said it better than I can:
What do we expect an App Server to do? (Score:1)
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.
Re:Speed? (Score:1)
Re:WebObjects = Java (Score:1)
Just gotta get rid of the Objctive-C zealots...
WebObjects = Java (Score:1)
Runs on Solaris, HP-UX, NT and MacOS X
Re:java? really, why? (Score:2)
Re:Enhydra (Score:1)
The development environment is good. We've made modifications to the Enhydra code in various areas and the response from the Lutris people in accepting and folding in the code has also been good.
From postings on the mailing list, it appears that the usage of Enhydra is growing. Fortunately this is being matched by the submissions of bug fixes and new features from developers.
Unfortunately, I can't objectively compare Enhydra to other app servers, however before we began this project, we did review a number of servers, including Locomotive and finally settled on Enhydra.
Re:PHP3 && mysql (Score:1)
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.
Re:HotSpot / Tower J / etc support for Java App Sr (Score:1)
+ 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
Re:HotSpot / Tower J / etc support for Java App Sr (Score:1)
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?
Re:A word about application servers (Score:2)
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.
Re:Dumb Question? (Application Servers vs Everythi (Score:1)
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.
----------
Recommendations (Score:1)
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!
---
Re:PHP3 && mysql (Score:1)
call the classes and get the information out of them.
---
links that will work: (Score:2)
Protomatter [protomatter.com]
Enhydra [enhydra.org]
That's almost a haiku... (Score:1)
How about widening the box for /. posts? (Or telling newbies they don't have to hit return overly much?)
-B
Re:Apache JServ! (Score:1)
Re:Enhydra (Score:1)
Enhydra has been my choice. (Score:2)
- 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 [ejboss.org]
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.why bother with an appserver? (Score:1)
Re:Speed? (Score:1)
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.
Re:Does Apache/JRun scale? (Score:1)
Re:No more politics, please! [Re:java? really, why (Score:1)
Mine is Blazing.. Must be your app server... (Score:1)
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!
Apache JServ! (Score:1)
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.
Commercial App Servers and a bit about JServ & (Score:1)
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...
WebLogic from BEA Systems (Score:1)
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
Re:writing servlets (Score:1)
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
I wrote the protomatter stuff (Score:2)
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
Re:Speed? (Score:1)
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.
Re:Java/Apache (Score:1)
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.
Re:PHP3 && mysql (Score:1)
p.s. sorry for the fscked up links, coulda wsore i did them correctly
Re:Solutions?!? (Score:1)
Re:BEWARE JSP: there be dragons in there (Score:1)
WebObjects (Score:2)
Re:Speed? (Score:1)
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.
Re:Speed? (Score:1)
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.
Re:Speed? (Score:1)
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 [beasys.com] 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.
Re:Speed? (Score:2)
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.
SCO Tarantella as a commercial product choice (Score:1)
SCO Tarantella [sco.com]
Speed? (Score:1)
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
Re:Speed? (Score:1)
The Tengah (sp?) Server brought NT on a P/166,64MB to an aprupt halt, no chance but 'reset'. A PII was needed as a minimum to run the server at all. This is where my guesses on speed stem from.
But its good to hear that things are not necessarily that bad. I like programming Java very much, but speed kept me back.
Java/Apache (Score:1)
There are two Apache/Java integration projects that I know about; one was already mentioned, the Jakarta project [apache.org] (jakarta.apache.org), "dedicated to providing a high quality, world class 100% Pure Java Servlet and JavaServer Pages implementation", and the Java Apache project [apache.org] (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 [apache.org] (similar in function to mod_perl [apache.org] or mod_php [apache.org]), client applications [apache.org], and a document publishing framework [apache.org] 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 [mailto]Re:PHP3 and mysql (Score:1)
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.
URLs? (Score:1)
FunOne
Help me slay the Microsoft beast! (Score:1)
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
Re:HotSpot / Tower J / etc support for Java App Sr (Score:1)
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
Re:Speed? (Score:1)
The cost is that you pay a stiff penalty for crossing the client/server boundary, so that it is actually faster to have a stupid client (pure html/forms) that sumbits large requests than a smart client (java) that chats a lot with the server and tries to do processing locally. Don't forget that serialisation is SLOW too, so with smart clients you have to resist the temptation to send objects back and forth across the connection.
This is really the same lesson computer people relearn all the time: Be stupid quickly, rather than smart slowly. (risc/cisc, ip/atm)
Johan
Re:No more politics, please! [Re:java? really, why (Score:2)
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
Yeah, that's right, alienate the newbie. (Score:1)
ATG Dynamo (commercial) (Score:2)
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.
Mason (Score:1)
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.
Re:Speed? (Score:1)
>256Megs of Ram, and it was only just
>bearable. Imaginig some
So you were programming gui's in java? Then I can understand, but serverside? I program servlets that run on any from a 486/40 mb to Sparc to Pentium-III and it all works fine.
I have a 486 running 6 full e-commerce shops and it works fine.
Ok it's not going into the millions of users, but for a 486 it is more than ok.
Quite possible that another solution would do better, but how much AND AT WHAT COST? Developing in ugly perl, making updates a real hell?
Using C++, which takes a lot more time to implement?
Php is nice, Zope to, I must say.
But comparing to something like enhydra, it fails miserably; XMLC is very good... No more mixing up of code/html, making updates a breeze...
If someone writes a brilliant, extremely fast XML appserver in C++ (GPLed ofcourse) then I would consider looking there.
It should be capable of using Python, Java, C++ etc as scripting/programming though and not some weird, unsupported homebrew shit.
FastTemplates is the answer (Score:1)
FastTemplate Tutorial [phpbuilder.com]
And yes, of course, PHP is not the right tool for every job. The same is true for Java.
Re:What about Zope? (Score:1)
Then try PHP [php.net].
You won't want to revert to Zope.
Re:PHP3 && mysql (Score:2)
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 Not Crap (Score:1)
But perhaps I missed your point?
Re:PHP3 && mysql (Score:2)
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.
Re:PHP3 && mysql (Score:2)
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 [openmaster.com] supports them.
Best regards
Ismael Ghalimi [mailto]
HotSpot / Tower J / etc support for Java App Srv? (Score:3)
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