charles,
thank you very much for an unbiased review of the servers.
marc
|-----Original Message-----
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Charles Crain
|Sent: Thursday, October 12, 2000 11:50 AM
|To: jBoss
|Subject: Re: [jBoss-User] jBoss or Enhydra ?
|
|
|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]
|
|
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
