First of all, Rickard is right, if all you are looking for is an EJB
container, you will be talking about JoNaS, the EJB component of Enhydra. I
have not use all of Enhydra, BUT I have used JoNaS, so I will try to compare
and contrast here.
First of all, let me just start by saying that having evaluated both, I
personally chose jBoss for several reasons which I'll go over after my
(somewhat) unbiased comparison of the two:
JoNaS advantages:
- decent EJB 1.1 compliance, better than most anyway (such as Allaire JRun).
There are a few problems, like the ejb-jar.xml file doesn't go in the
META-INF directory, so you will at least have to re-jar beans from a fully
compliant server to deploy them on JoNaS.
- Easy to configure data soucres and set up finder methods for entity beans
- True distributed transaction management using their own transaction
server, able to coordinate transactions between different machines
- Ability to obtain a UserTransaction object from a remote client
(application client), albeit NOT in the standard J2EE way.
- Fairly stable
- Used with Enhydra, you get a JMX (Java Management Extension) enabled
server that allows easy remote management.
jBoss advantages:
- Proxy-based deployment!!!! You don't need to generate stubs for your
beans, that's all done automatically, just copy your beans into the deploy
directory, and they are automatically hot-deployed.
- JMX-enabled server with finer grained component architecture than JoNaS.
Whereas in JoNaS, the whole EJB server is a component of Enhydra, with
jBoss, the auto deployer, bean container, tx manager, etc. are all
components.
- Very good EJB 1.1 compliance
- Graphical deployment tools allow you to set up data sources, finder
methods, etc.
- Rapidly evolving J2EE compliance...for instance, the ability to obtain
user transactions via the standard J2EE method for in-VM EJB clients is
either in the works or already there.
- Actively developed! Reported bugs are typically fixed within a couple
days, and new features are always popping up. Even EJB 2.0 support is in
the roadmap.
- Several advanced features, such as the ability to load classes dynamically
from clients, so you don't have to put ANY extra jars (apart from the
standard ejb.jar and the interfaces for your beans) in the client's
classpath.
- Takes advantage of several new features in the new (faster, better) JDK
1.3
- Clustering support coming soon! This is a feature typically only seen on
$10,000+ per CPU servers like WebLogic. And as I understand it the
slickness of the implementation (Jini-based) will blow WebLogic smooth out
of the water.
- good documentation, particularly for a young open source effort
JoNaS disadvantages:
- Somewhat clunky deployment. You have to generate stubs for your beans
using a tool called GenIC, edit some configuration files, stop the server
and run it again every time you re-deploy. Not terrible for deployed
systems, but a huge pain for development.
- Everything runs in a separate VM. In fact, all the examples have EACH
BEAN running in its own server, in its own VM. To run multiple beans in the
same VM, you have to edit some configuration files.
- The JNDI provider is our old friend the RMI registry. This has several
limitations, including the fact that you have to have rmiregistry running
(presumably in its own VM), and all the classes served up by rmiregistry
have to be in the rmiregistry's classpath. It also does NOT support
sub-contexts, so JNDI names like "interest/InterestHome" are impossible.
- The JoNaS distribution does not ship with a lot of necessary jars, and you
have to manually download them from java.sun.com, install them, and tell the
config files where they are.
- No pooling! Ack! Although several EJB resources (stateless session
beans, JDBC connections, passivated beans, etc.) are specifically designed
to be pooled, JoNaS does NOT do this. This means some significant
performance hits compared to EJB servers that pool (which is just about
every other one).
jBoss disadvantages:
- Still somewhat unstable, so if you need rock-solid performance, you'll
have to wait (and/or help out!)
- No distributed transactions. Transactions are capable of being propagated
within the same VM only, not to other VM's on the same machine, and not to
other machines. Of course, you still have distributed transactions in terms
of transactional RESOURCES, so for instance you can still run your Oracle
database(s) on different machines. There is talk on the development group
about implementing this however.
- No ability to obtain a UserTransaction from an out-of-VM client
(application client). This is not mandated by the J2EE specification, and
clients that rely on this behavior are by definition non-portable, but
several other EJB containers do provide this service.
In summary, I chose jBoss because of the better standards compliance, the
ease of bean development, the richer feature set, the better performance
(mainly due to better JNDI implementation and pooling), and the fact that
most if not all of the disadvantages I listed above will most likely
disappear within the next few months.
Hope this helps,
Charles
----- Original Message -----
From: "Jerzy Brzezicki" <[EMAIL PROTECTED]>
To: "jBoss" <[EMAIL PROTECTED]>
Sent: Thursday, October 12, 2000 9:25 AM
Subject: [jBoss-User] jBoss or Enhydra ?
> I new to EJB and I am not trying to offend anyone here with this question
so don't flame me :)
> I just need some infromation from people who have experience with both of
those servers.
>
> Can someone who worked with both servers briefly compare both of them ?
> I am going to work with apache+tomcat+ some application server (jBoss or
Enhydra) using VAJ.
>
> Thanks,
> Jerzy
>
>
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Problems?: [EMAIL PROTECTED]
>
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
