A. Kevin Baynes wrote:
Yes. One "anti-pattern" to avoid -- even if you're on WebSphere -- is to "roll your own" just for compatibility's sake. Meaning I'd rather see 100 com.ibm references than one org.me cache implementation because we're all vendor scum and will do things a similar way :-)Thanks, Andy!
If I understand you correctly, then the simplest thing for me to do is
to pick an app server and write to it specifically, only taking on the
task of porting to another app server as a last resort, right? If that
is the case then it will probably be JBoss.
You don't have to go out of your way to be incompatible, but focus on scaleabilty and performance first. (of course code quality and testability don't hurt ;-) )
BTW, by the three major app servers you mean WebSphere, BEA and JBoss, right?
Yup.
Thanks again for your insight and for taking the time to respond.
sure man.
-Andy
~akb
On Sat, 08 Jan 2005 20:16:52 -0500, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
A. Kevin Baynes wrote:
In theory, one should be able to create an application that is portable between application servers, correct? In practice, how difficult is this?
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.
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.
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?
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.
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)
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?
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)
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
_______________________________________________ Juglist mailing list [email protected] http://trijug.org/mailman/listinfo/juglist_trijug.org
