A high level overview of todays common application servers has been made available in first draft form for public use and input. The thesis covers JRun 3.1, ATG 5, BEA WL 5.1, Borland 4.5, Jonas 2.3, Fujitsu Interstage 4, HP Bluestone 7.3, Websphere, IPlanet and more.
This review is part of a thesis on application servers.
In a first phase, I have done a high level overview of the market, browsing supplier's sites and user forums to cover criteria like documentation, support, administration, EJB development and special features. I spent one day on each server. I've also contacted the vendors for additional info.
I've covered all EJB servers from http://www.flashline.com/components/appservermatrix.jsp
The document can be found at:
(MS Word Doc)
I invite everyone to review and discuss my results. I will incorporate helpful input and continue to rework and try to improve the document with your input.
I hope that this can be a timesaver for reviewers doing the first knockout selection.
This is great summary of the publicly available information, and good start for those who want to make a choice.
There is a few bugs in report ;) In report about weblogic title says Weblogic 5.1 but you presenting features of weblogic 6.x.
In report about weblogic title says Weblogic 5.1 but you presenting features of weblogic 6.x.
I've indeed reviewed WL 6.1. (Damn typo)
I've discovered other errors as well and post a new document soon.
I have also reviewed Sybase EAServer and Unify eWave. The next version of my document will include my conclusions on these servers. (Note that those are the two last EJB servers on the Flashline matrix... ;)
Finally, I have discovered that the Flashline matrix doesn't include the Trifork application server. I will have a look at this server soon. Anybody who can tell me about his experiences with this one?
Pieter Van Gorp.
I think the report is messed up, at least for WebLogic Server. If it is talking about WLS 6.x than why is JDK 1.2 specified as supported, and not JDK 1.3?
The WebLogic one has to be revisited. I believe the product that you are (or should be) referring to is "BEA WebLogic Server 6.1", not WebLogic Enterprise 5.1. WebLogic Enterprise is a totally different product from BEA that has to do with CORBA/Tuxedo.
Regarding the JDK, WebLogic Server 6.1 requires JDK 1.3 on the server side, but a client that accesses the server can be running 1.2. The reason for the 1.3 requirement is to do with a ClassLoader fix in that version.
This is a nice overview, however what this really is, is regurgitating info from the vendors. What would be *really* useful, is getting experts in the field to discuss app servers that they are expert in.
Regarding the JDK, WebLogic Server 6.1 requires JDK 1.3 on
>the server side, but a client that accesses the server can
>be running 1.2. The reason for the 1.3 requirement is to
>do with a ClassLoader fix in that version.
I think 6.1 requires 1.3 on the client side (if the client uses RMI) because WebLogic does not generate stubs anymore and uses dynamic proxies.
1.2 or 1.3 is supported on the client, 1.3 only on the server. Dynamic proxies are available under 1.2, so that is not an issue. I can't remember why 1.2 isn't supported on the server... perhaps just because the 1.3 VM is more stable, and it is easier to get customers to upgrade the server than the client.
Good point about this paper being basically a cut 'n' paste from various reviews.
I am currently looking at Sybase's EAServer product and Microsoft's Application Center 2000 (doing a M$ vs. J2EE evaluation). We are a PowerBuilder shop, so EAServer is a logical next step. In our evaluation, we have found that a lot of things in brochure don't shine nearly as bright when you try to implement them.
While I'm not familiar with BEA or IBM's offerings, Sybase serves up a pretty decent tool. However, on the downside, the GUI (Java Swing) suffers from the usual problems in terms of responsiveness and occasionally has very long pauses in execution, and sometimes fails to respond at all. Mainly I'm referring to the administrative tools of the server. The M$ tools are pretty bullet-proof.
Another note: EAServer has a very attractive feature called "in memory" failover. When experimenting with a cluster of NT/2000 machines, the idea behind your server cluster is not only that it's always available, but that processes which fail during execution are picked up by another machine. I'm not talking about re-sending the request or starting the process over, but actually picking up where you left off.
It's a neat idea and in my opinion, the major stumbling block to NT/2000 platforms - UNIX based systems still are more reliable. While a cluster is inherently highly available, fail-over is more than that - it means making sure that currently executing processes complete, even if the machine they are running on is powered down.
I haven't completed my testing, but this is one area where M$ doesn't seem to have a good response. I can run my J2EE application on a Sun E-series machine and get reliability. But M$ stuff runs only on Windows, and to get anything comparable, you've gotta has in-process recovery.
I'll post again when complete with a review of the results...
Hmm, though this is a bit OT, I just have to say that, though EAServer is logically the next step for you, I'd use another AppServer for the comparison.
We currently are in a project where EAServer was chosen as "the logically next step" (because they used PowerBuilder) and they were not very lucky with it.
In the end they replaced Sybase with Borland AppServer which they are very lucky with now (They nearly stopped the project because of EAServer).
Additionally, PowerJ delivered with EAServer is IMO a bad IDE, I once read a quote "[...]PowerJ cannot distinguish J2EE compliant code from a bowl of froot loops[...]" ;-)
That's not my favourite argument against PowerJ, but its funny ;-)
You should probably try JBuilder/AppServer combo (which is very good and easy for development), or BEA, Bluestone (which is a bit more compley but very powerful).
Just to warn you, would be sad if you chose Microsoft instead of J2EE just because of a "not so good" server.
"Another note: EAServer has a very attractive feature called "in memory" failover. When experimenting with a cluster of NT/2000 machines, the idea behind your server cluster is not
only that it's always available, but that processes which fail during execution are picked up by another machine. I'm not talking about re-sending the request or starting the process over, but actually picking up where you left off."
duh ... welcome to the real world!
WebLogic has had this for years now!
For all people who want to have a quick overview about clustering services in WebLogic Server v6.1, I recommend reading this
introduction guide. On page 2-9, 2-10 you can read that stateful session beans can always be clustered using in-memory replication to provide failover. Read-Write Entity beans however, are "pinned" to the server where they are instanted. If this server fails, the application must create a new instance. This means this process is not picked up automatically by another server.
Stateless session beans and ready-only entity beans can always be clustered in WL. I don't know yet which mechanism is used for this types of beans.
PS: George, on page 3 of my first document draft, you can read "In-memory replication for stateful session EJBs in a cluster" as a special feature. Doesn't this refer to what you are meaning? Or does it suggest that requests need to be resent? I could write "In-memory failover for stateful session beans in a cluster" if this is more clear.
Yes. "in-memory replication" is a critical HA feautre and are only found in high-end application server. It avoids the single point of failure.
I only know WLS, WS, EAServer, Rexip supports such feature. Do you know the others?
This is a nice overview, however what this really is,
>>is regurgitating info from the vendors.
>>What would be *really* useful, is getting experts in the field to discuss app servers that they are expert in.
It is indeed <b>an overview</b>. Nothing more, nothing less.
I have posted the document here, because I've spent a lot of time reading "expert" reviews (including all discussions in the Reviews section of this site) but couldn't find a concise overview of todays market. I hope my document can be a timesaver for anybody facing the same problem.
As noted in the announcement, this overview is only an introduction to my thesis. I have selected 2 application servers for further personal analysis. Maybe, I can give you expert advice on these server by the end of the year...
In the mean time, it is indeed very usefull if all experts out there, correct my overview where I am wrong.
Pieter Van Gorp.
Also, in the "Special" Section, if you don't list "XA/2-Phase Commit" does that mean that the particular product does not support it? e.g. is there a standard list of extras that you are checking off against, or what?
Also, in the "Special" Section, if you don't list "XA/2-Phase Commit" does that mean that the particular product does not support it?
>> e.g. is there a standard list of extras that you are checking off against, or what?
The "special features" section contains an enumeration of
1) what the vendors want to emphasize on their product sites
2) items that forum users (the "experts" mentioned somewhere else in this thread) bring forward as a special feature
So I cannot (nor want I) garanty that a product without "XA" in that list, does not support the feature.
The downside of this approach is that it may suggest what you were thinking of.
However, it allowed me to give a list of features without having to mention every feature a vendor advertizes on his site. You've got a very good point about leaving the XA feature out of the list, I've thought about doing that already. What do you (or others) suggest?
Pieter Van Gorp.
Granted that XA/2PC is not part of J2EE, yet, but I think it belongs in an app server overview. Why leave out a feature that enables the app server to scope transactions across more than one resource manager? I know of more than one customer that actually need that feature.
Exceptionally good job...I will def give some feedback soon. Currently evaluting EAS from Lutris.
Sorry, I was mistaken (thanks Dimitri). The JDI 1.2/1.3 support was for 6.0, not 6.1. In 6.1, it's 1.3 for both.
We confirmed using Bean-test (my company's testing tool) that a WebLogic6.1 for Solaris client only works with JDK1.3 or newer. I did not try for Windows since we provide the 1.3 JDK with that, but I believe it is the same thing.
We confirmed using Bean-test (my company's testing tool) that a WebLogic6.1 for Solaris client only works with JDK1.3 or newer.
>> I did not try for Windows since we provide the 1.3 JDK with that, but I believe it is the same thing.
I'm really sorry for all confusion I may have caused concerning BEA WebLogic.
Since I'm only planning an update of the doc by the end of the week, here's some explanation for BEA:
I reviewed WebLogic Server 6.1, but the title and JDK version refer to an older Enterprise edition. The JDK version that is advertized for WL Server 6.1 is 1.3.1.
The error is due to a mergin error of my document with a first draft.
Note that the update I will post by the end of the week will contain other "bugfixes" and reviews for Sybase EAServer en Unify eWave ... consider it a "service pack" ;)
Borland AppServer 4.5 _does_ support EARs and WARs (in fact, you AFAIK cannot get certified without doing this).
Would probably also be nice to mention the powerful console, which is IMO far superior to the "Web Consoles" provided by BEA, IBM, etc.
Bluestone: I wouldn't say the management tools are "difficult to get used to", in contrast IMO they are very easy to use, its just that you have a lot of power with them, so they are quite complex.
Thanks a lot, that's the kind of feedback I really appreciate! I'll post an update one of these days.
I have been confused by an outdated review: https://www.theserverside.com/reviews/thread.jsp?thread_id=290
I should have checked it myself, but then I wouldn't have finished my review within acceptable time.
Pieter Van Gorp.
Thanks to you Pieter for having the balls to post your work.
And thank you for making my day!
Shame that too few of these reviews do not contain performance figures. Personally, I'm really sick of all the proprietary "we're the fastest" statements from alla appserver vendors....
Posted by Eje Thorarinsson 2001-10-15 04:40:53.0.
>Shame that too few of these reviews do not contain >performance figures. Personally, I'm really sick of all >the proprietary "we're the fastest" statements from alla >appserver vendors....
Our app server review has extensive perfroamnce analysis - see:
It's not free, I'm afraid - wish it were!!
Can you please use your experience from your qualitative analysis to review my overview ... for free?
Thanks a lot,
For PowerJ 4 their is a completly new IDE and their has been a major re-write of the tool. This is in beta at the moment.
This is a great document. Finally someone has gathered the information in a single format.
Unfortunately, I think a performance chart comparing the servers in differing situations on similar hardware and OSs would be helpful. For example, it would be useful to have different charts measuring the performance of separate JSP/Servlets, DB calls, JSP/EJB, etc.
The Contra section of Silverstream Application Server mentiones "instability". I have worked with this application server for months and I also worked with people who have used them for years (pre J2EE era). None of them encountered this negative comment however.
The Contra section of Silverstream Application Server mentiones "instability".
>> I have worked with this application server for months and I also worked with people who have used them for years (pre J2EE era).
>> None of them encountered this negative comment however.
Thank you for sharing your experiences.
First, let me explain something about the "contra"-section:
How did I make up the downsides of an appserver? As you can guess, not by browsing vendor's sites. Since I had to make a quick overview of the market, I rely on common experiences of users. These can be found in the Reviews section of this site and in magazine articles.
Please do not think that I included any negative user experience in the "contra" section of my review. Only when a lot of users agreed on it.
A lot of people complaining about the instability of Silverstream can be found in https://www.theserverside.com/reviews/thread.jsp?thread_id=5746
Thank you for noticing that you and others have had nothing but positive experiences. However, if I simply ignore the claims made in the thread above, I'm not able to give any negative comments, apart from things like the EJB version supported.
For the installation process I had to rely on the same approach.
I hope you understand that, as a student, this is the only way I can make such a review within acceptable time.
Huh... they make it sound like the lack of GUI deployment tools is a bad thing :P
could you give some additional information about the meaning of the "pricing" column (CPU?, Dev?, multiple prices?)
That's basically a copy-paste of the info in the FlashLine Matrix
Since it is quite vendor specific what "a Dev licence" etc. is, I recommend you to visit the vendor's site or contact one of their sales people before making your decision.
I've only provided the pricing info to give the reader an idea in which category a given server belongs.
I haven't reviewed Trifork yet.
Who has experiences with this appserver?
I find that orion application server from www.orionserver.com is cheap (only $1500 per server, free development licenses) and works 100%. What else do you need?
That and only jakarta project velocity (template engine), jakarta project ant (build tool), jakarta project log4j (logging library) and poolman object pooling library (sql connection & resource pooling) you can develop GREAT system :)
The price tag differs quite a lot from vendor to vendor. So I think the price should be either left out or deeper specified. For instance, some vendors do not have additional pricing for load balancing, clustering and failover, but many has. So the initial pricing on a per CPU-basis is just not enough.
do you know where can I find the document?
the link is not working (2003-05-28)
Can anybody point me to a similar doc elsewhere?