A. Kevin Baynes wrote:
First off, I work for JBoss so I'm at least as fair and balanced and unbiased as FoxNews on the topic. I'll give you some pointers, and you can fact check me yourself.In theory, one should be able to create an application that is portable between application servers, correct? In practice, how difficult is this?
There are a few problems. One is that CMP (container managed persistence) isn't "really" portable at all. Allow me to explain, the class files that you compile are portable. The massive XML configuration isn't portable (the class file is the small part of your labor). Also certain behaviors are left up to the implementor and certain aspects of each appserver work better than others. That causes you to favor certain alternatives that you wouldn't use on the others.
For instance, in JBoss, a CMP using commit option A is feasible in a cluster provided without exclusive access to the database if the data is "insert only". According to the WebSphere documentation (I posted the link in the slides to the talk I gave on how to screw up your app), this will not work in WebSphere. Thus on WebSphere I might end up using either a third-party cache for said insert only data or not using a cache at all, where on JBoss I might use cache for that same data.
In turn, JBoss 3.2.6, 4.0.1 does not have a production-ready system for XA transaction recovery. With WebSphere it is an option that you can buy. With JBoss you have to buy it from a third party vendor, Arjuna. (there is some beta code that was committed yesterday...literally)
WebSphere's clustering features and JBoss's are based on significantly different technologies and may behave differently and support different topologies and failover semantics better. WebSphere's clustering is based on IIOP. JBoss's is based on dynamic proxies and JRMP. JBoss's invocation stack is easily modified/joined. WebSphere's is not so easily modified. WebSphere more or less is "proxied" with a failover manager type setup. JBoss's uses udp multicast. This ultimately affects the design decisions you make in larger systems.
Okay so I'm partisan, and of course JBoss is the world (and now has the #1 market share overall as well as in embedded products). Honestly, there are three appservers with any considerable marketshare and the gold standard is -- while a matter of opinion as to which -- one of the three. Sun is not one of them. Also they have not only switched code bases (supposidly) multiple times but they have renamed the product so many times that its really hurt their chances, the latest incarnation is the worst naming yet.The company I work for has relationships with IBM and JBoss. I'm rewriting a webapp to take advantage of services offered by an application server and I would like to support WebSphere, JBoss, and Sun. Is this a practical goal?
A truly drag-and-drop non-trivial application will not perform well (you trade performance for compatibility). You won't be able to take advantage of the appserver. According to most customers who use WebSphere, you'll find that creating descriptors for WebSphere nearly impossible without their development tools which limits the robustness of your build process. You'll also not be able to take adavantage of some of the more advanced features of each. XDoclet support for JBoss is great, its not so great for WebSphere.
That being said. To mitigate this:
1. Hibernate can be used on both WebSphere, JBoss (and presumably Sun but I know few people who use Sun), and Sun. JBoss Inc actually provides support for Hibernate even on other appservers. (And I believe you can use your support contract to that effect -- but I'm on the tech side so don't quote me on that)
2. JBoss AOP can be used on either appserver as well as in plain Java. You could use JBoss AOP to work around many of the remaining portabiltiy issues. (again supported)
3. JBoss Cache can be used on either appserver as well as in plain Java. (again supported without JBossAS)
JBoss is open source. Secondly, you can remove unused services from JBoss and even extend it with your own (microkernel architecture). JBoss is the #1 embedded according to the analysts. Both JBoss and Sun are well supported. (I've generally been more impressed by Sun's technical support as a competitor than IBM's and its more affordable, though I imagine IBM is better represented locally)Also, our default distribution will probably be bundled inside of either JBoss or Sun, since they are freely redistributable. Is there any 'big' advantage to using either one?
Both IBM and JBoss can give you local on-site support.
-Andy
Thanks!
~akb
----------------------------- A. Kevin Baynes
_______________________________________________ Juglist mailing list [email protected] http://trijug.org/mailman/listinfo/juglist_trijug.org
_______________________________________________ Juglist mailing list [email protected] http://trijug.org/mailman/listinfo/juglist_trijug.org
