Opinion: J2EE = Just 2 Existing Enterprises OR J2EE 2 End Early


News: Opinion: J2EE = Just 2 Existing Enterprises OR J2EE 2 End Early

  1. With BEA and IBM dwarfing the rest of the J2EE servers in marketshare, I have heard many developers imply that other J2EE server vendors should simply give up and focus their attentions else where. Could this be the end for many other companies trying to bring quality implementations to the J2EE arena. Are we going to let history repeat itself?

    I feel that this debate deserves to be placed as a news item. I wanted to begin a thread from which I can gauge how true the notion is that the battle for J2EE servers are over..

    I would like to hear peoples views, if this was ever to become true. This really troubles me and I hope it does many others. I would not like to think that I am alone in this regard, so lets debate it here and figure out the truth.


    William Louth

    Threaded Messages (112)

  2. J2EE app servers are becoming commodities now. Vendors need to and already start to differentiate themselves in what they offers (in addition to the infracture implementation of J2EE Spec). It is clear that WLS and Websphere are taking the lead and everyone else in a remote third. The good news is competition is stiff and we see many app servers start to deploy components and services which can run on top of other application servers.
  3. Please everyone. Don't get marketshare and price into which appserver is the best. Even If I had all the money required to purchase any of WebLogic and WebSphere I wouldn't for one very simple reason. They suck! The only reason for them being ontop is because they have a whole lot of money to poor on marketing.
  4. At least four people here have equated J2EE servers as commodities, and I've also read an article a couple months back (JavaReport?) regarding the commoditization of J2EE servers... To me, commodities are orange juice and pork belly: unambiguous, undifferentiable, and simple to use. J2EE servers are ANTHING but those traits!

    Case in point, I've been using BEA Weblogic for close to 2 years now, from 4.5.1 to 6.0; I have a couple of BEA Mentor of the Month awards under my belt, and I feel like I am almost a veteran in the app server field. Well, 6.1 just came out a month ago, and up till now I still CAN'T GET THE DAMNED thing up and running with our application! The complexity of app server is borderline ridiculous! And why don't I have the time to eval other app servers? Because I know it will take days just to set them up, and weeks to get our application running on them. My job is to write business codes for my company, not container shopping!

    App servers are FAR from commodities; vendors still have problems interpreting J2EE specs, and heck, Sun still has problems with the specs themselves! Is there a market for other app servers aside from BEA and IBM? Yes! Is there TIME to try out all these? NO! The day J2EE server become as easy to use as java runtime is the day we can call it a commodity; and by definition the commodity will be so homogenous and undifferentiable that it will not make sense to have more than one vendor produce them.

  5. Ah well, maybe you should try Borland AppServer... I know I'll get flamed, however, try it ;-)

    kind regards


  6. Gene Chuang wrote:

    "Well, 6.1 just came out a month ago, and up till now I still CAN'T GET THE DAMNED thing up and running with our
    application! The complexity of app server is borderline ridiculous!"

    Gene, what seems to be the problem? I have a very complex app that I was able to deploy on WLS 6.1 without any problem whatsoever. The upgrade from 6.0 was a breeze and the thing works like a charm.

    I can't believe that you spent a month trying to get your application to work with 6.1 ...
  7. Hi George,

    Consider yourself lucky! Now I know of many people who also got WL 6.0/6.1 up and running seaminglessly... unfortunately, I managed to hit almost every snag conceivable with my application and 6.0/6.1, and have 15 BEA Support cases to show for it! (All 15 are confirmed regressions and promised to be fixed in future release, so I'm not just crazy and imagining these bugs... :-)) If you think your application is complex, take a look at ours!


    We use every API stipulated in J2EE, every engine/service provided by BEA, and then some: EJB, JSP, Servlet, JDBC, JMS, JTA, Taglib, Startup/shutdown classes, Apache Plugin rewrite engine, web/app cluster, session replication, etc... In fact, I'm considering licensing our application back to BEA as a regression test suite for their server! :-)

    I'm not here to bash BEA, but J2EE in general: it's still too complex! Like it or not, we are all beta testers for J2EE, a 2 year old technology that is still evolving and changing, and trying to define its own identity. I hope someday J2EE server will be incorporated into Java Runtime, and will be just as simple to use. These days we really don't worry about "java" failing, or have to decide which "java" version to use!


  8. Gene,

     Personally I am never convinced with the Idea of having Web Tier and EJB Tier on different Servers. (I guess you too Agreed with this point).
     Also I am not convinced having Session Replication for every Application. I believe In most cases its just a money making opportunity for App Server Vendors. With Servers like Weblogic (Where production system very rarely see servers going down) its far less a requirement than it used to be.

  9. Session replication is not just for system failure. We release new versions of our app a lot (several times a week). We don't want to have to take the system down so we use HP Bluestones hot versioning. Part of this process is maintaining session state through the transition.
  10. Jordan,

     I agree with you. But what % of J2EE applications push version to production several times a week and wants "0" maintanance time?

  11. Gene,

     .. I feel like I am almost a veteran in the app server field. Well, 6.1 just came out a month ago, and up till now I still CAN'T GET THE DAMNED thing up and running with our application!

    My job is to write business codes for my company, not container shopping!

    While it is true that the job of developers (yes, I'm not talking off my rocker - started as one, still consider myself one) is to write business code, but development ease, deployment & maintenance are key factors as well. The EJB spec's attempt to separate - (the role not necessarily the person) - a bean provider (aka developer) from a deployer and an administrator is commendable but speaking from experience - the lines are blurred (non-existent?). So finding the right tools & vendors that make those an ease are a must. (Someone posted here a criteria list - and I would add "Tools" to that as well - tools for development, deployment & maintenance.)

    In my previous job, we had to choose an EJB server vendor (about two years ago). The management in that company was all for one of the market leaders at that time and we eventually started out on one of them. 6 months into the project, we changed vendors - primarily because of being unable to meet project schedules as a result of lost development time. Developers has to switch between GUI development tools, running command line utilities and fiddling around with settings & properties. Today things are different - Borland's JBuilder supports a multitude of AppServers. Together/J supports a few as well. I do not know about VisualCafe's support for products other than WebLogic and then there's IBM's VisualAge and even Pramati's Studio.

    Much of the decision (if technical) is based on a personal feeling for the product & provided tools and technical infrastructure. Otherwise why does this site (and other ejb related lists) generate so much emotion & traffic :)

    Just to say - I agree with your statement & sentiment "Is there a market for other app servers aside from BEA and IBM? Yes! Is there TIME to try out all these? NO!"

  12. I agree. J2EE servers becoming commodities makes sense for Open Source implementations. See the growing work around ObjectWeb http://www.objectweb.org or JBoss.
  13. I don't agree with this at all. We're using HP Bluestone and are very happy with it. Further, I know that HP is actively promoting and updating it. I'm sure they're not the only vendor doing this.
  14. I agree, and I do NOT think that the other vendors should give up. Competition is good for all, and I think there should be choices available to pick from, otherwise you will just end up with a Microsoft type environment, i.e. one choice.

    Just because they are the two biggest market share holders, does not mean they are the best implementations, or the right ones for a given company and/or project. Some companies may not want all of the frills that these two vendors provide, they may just want or need a good, solid J2EE appserver and nothing else.

    Cost is another consideration. These two are not cheap by any means, and some companies just cannot afford to buy the licenses needed to run them. This is where the JRuns, Orions (outside of Oracle) and the open source servers like JBoss and Enhydra will come into play.

    It is a sad fact that the people who usually make such large purchase decisions are not the ones that have to develop, deploy and live with those decisions, and all they see and hear about is IBM and BEA.

    Robert McIntosh
  15. I cannot agree with you more. Most of the people who are involved in purchasing app servers are senior management officials, especially because of the price involved. A lot of then don't even understand what is involved in developing a J2EE application, let alone integration related issues. Eventually as a developer/Architect you are left with the momentous task of trying to make it work in an environment that has products you need to integrate with, only because these products were already bought. The sales people can convince anything to anybody in the upper management because most of them have not developed anything in their life. It is also sad that most companies need everything up and running, yesterday. Then you make compromises that are against most software engineering principles. I have even seen projects where the client did not want the design phase, because they thought it was a waste of time from the deliverables stand point. Consulting companies would do anything to get a project. Clients dictate how the development should be done. Yes, they pay big bucks right, I agree. But, they hired consultants because they did not know how to do it in the first place. In a nutshell, unless you are a working for a big corporation, modeling tools are becoming a luxury item in this industry (as sad as it may seem). The prohibitive costs os the modeling tools like Together and Rational does not help the case either. It is very difficult to convince management the importance of tools and choosing the proper application server for the right job. For example, for a Corba/EJB based solution, integrating with back-end legacy systems, I would rather use IONA's iportal application server than BEA. Yes, iPortal's CMP sucks. Still, it is better suited to do this job, in my opinion.
  16. Well, I do develop, and I'm the architect for my company, and was the main decision maker for our choice. You know what? We went with BEA. The reason? Stability. There may be products that are better here or there than BEA, but BEA is a stable company, and I know they're going to be there in 5 years. <br>
    Where's Iona going to be in 5 years? If they're still around, and haven't been bought out, then they'll likely still be a small player in the App Server market, if they haven't moved on to something else, and they won't be on anyone's top 3 list for certifying their add-on J2EE middleware. The same goes for Borland and Silverstream. They'll likely all move into platform agnostic J2EE middleware. <br>
    Macromedia may stick around with JRun, but likely in a workgroup deployment role, and they'll probably face stiff competition from JBoss there in not too long, since that's a very price conscious market.<br>
    The one's I'm less sure of are Sybase and HP's Bluestone. From all accounts, HP's Bluestone server is an excellent, rock-solid server, but HP has not had a good track record with software other than OpenView. I haven't been keeping too close an eye on Sybase's fortunes of late. If the DB is still a significant part of their revenue, then I would expect that they're not doing too well. From a quick look at financial reports, it looks like they're losing money, which is not a good sign. <br>
    Overall, for enterprise software it's at least as important to find a partner who has staying power, so you don't end up with unsupported software, as it is that their product is technically the best. That's the whole reason Oracle is able to sell their app servers, because it's certainly not because of their technical merits.
  17. BTW, all appservers except for BEA are dependent on CORBA from IONA. BEA is still doing with some shitty implementation. And just look at the footprint of BEA - its mindboggling. Being architect does not mean your sanity is absolute. Its actually only relative to the people around you working with you. Sometimes, even political reasons do play important role in people's elevation to higer roles.

    Now as far as IONA's life in 5 years is concerned, it has lived for 10 years and that too rather succesfuly and I can bet as long as there are intelligent people existing on this planet, it will continue to be significant player.

    Vimal Kansal
  18. I think the following quote sums up the BEA and IBM implementations.

    "Species do not evolve toward perfection, but quite the contrary. The weak, in fact, always prevail over the strong, not only because they are in the majority, but also because they are the more crafty."

    Friedrich Wilhelm Nietzsche, German philosopher and poet.
  19. "Species do not evolve toward perfection, but quite

    > the contrary. The weak, in fact, always prevail
    > over the strong, not only because they are in
    > the majority, but also because they are the more
    > crafty."
    > Friedrich Wilhelm Nietzsche, German philosopher and poet.

    Nietzche was a nihilist, I would think twice before listening to what he has to say :-D

    (besides, basing your choice of application server on a quote from a dead philosopher negating darwinism is probably not very bright anyway)

  20. Cedric,

    The measurement of fitness is quite different here. Its based on perception and has nothing to do with actuals.

    It has already been stated that your implementation (weak) is really not a match for some other offerings (strong) but BEA was selected because the belief is that you will survive (majority & crafty).

    Some companies are good at making quality software products others are good at selling software irrespective of quality.

  21. The measurement of fitness is quite different here.

    > Its based on perception and has nothing to do
    > with actuals.
    > It has already been stated that your implementation
    > (weak) is really not a match for some other offerings
    > (strong)

    Oh but these statements are based on perception, they have nothing to do with actuals.

  22. Cedric,

    WRONG. I have used you software and will probably continue to use your software its part of my job.

    I usually have about 3-5 appserver vendors offerings installed and running on my machine(s).

    Have you used Borlands AppServer? Did you like it?


    You're probably a decent enough guy, why don't you just come out and say it

    "Hi, my name is Cedric and I am embrassed by the software coming out of my company."

    You will feel much better and maybe we can all learn to forgive you and eventually like you.


    yours sincerely,

  23. Disappointed[ Go to top ]

    It's a shame that the topic is degenerating from something that could be useful to these sorts of posts. If this is all that we have to say that I'd say it's time we ended this thread.

    Moving on,
  24. Disappointed[ Go to top ]

    I am terribly disappointed with William Louth's comments.
    He took things too personal.

    BTW look at William Louth's profile here. You will get it why he makes such stupid comments:
  25. Disappointed[ Go to top ]

    yes ... I agree.

    William Louth has been behaving more like a lout!

    william, is there a silent "h" in your last name?
  26. Disappointed[ Go to top ]

    Mettu and Billy,

    The last posting (aside) was actually a bit of a joke. Do you think Cedric was going to come clean ;-).

    Please note that I started this thread with the best of intentions.

    Billy, it was your reference to Jonathan and myself which allowed Cedric to enter this thread and take a little swipe.

    But I understand you might have not seen it this way. Apologies.


    Documents can easily become out of date. I HAVE NOT WORKED FOR BORLAND FOR THE LAST 4 MONTHS. I took some time off to build my own product and to show that quality J2EE development products can be built; even by one man.

    I have knocked BEA long before joining Borland regarding their tools so I now give them the opportunity to do it to me. ;-(.

    Now I must go and remind myself not to get wrapped up in Cedrics little antics anymore and stop thinking out aloud.

    William Louth
  27. William mentioned in his poreviously that he is not working for Borland for last four months but check out the other post by him(on aug 2nd he mentioned that he works for borland during day time) :

  28. Mettu,


    Again, I have not worked for Borland for the last few months.

    I have just recently (last week) removed any reference from my website that would imply that this was the case per instruction from Borland UK. I was unable to alter the serverside posting following this instruction.

    I do have an open contract with Borland PSO (NO PAY) which allows them to call me for some special cases (very rare) but this is simply to facilitate billing. I am also working for my own company (Inspired) while helping out some friends on other J2EE projects for their companies. Some of these projects do not even use Borland AppServer ;-(.

    It was a mistake of me to use Borlands name.

    I left Borland PSO because I wanted to develop products and the R&D option was not available to me. JDBInsight is the first of such products and I think you cannot deny that I practice what I preach. I do not deliver sub-standard software to users. All the products/projects I have worked on prior to joining Borland PSO have earned me much praise.

    I have yet to meet a (former) colleague who did not share the same view about my work.

    If you think I am harsh regarding BEA's offering you should have seen me on the Borland AppServer Aplha Test (June 1999). I believe my pursuit or demand for excellence in software has contributed to some degree to the quality of Borlands implementation. I did not have many friends in R&D at that time but I do have now.

    I hope now that you have a better understanding and that you see that my attacks on the poor quality of some vendors tools is not driven by other motives apart from trying to make sure that WE ALL GET SOME BETTER TOOLS FOR THE MONEY WE PAY FOR.


    William Louth
  29. William,

     I have Better things to do than looking for what you do.
    I felt Your comments on Cedric and BEA was based on your work with their compititor. I made my point(whether you like it or not).

     It was you who mentioned that you are still working for borland(In which case your comments on another App server vendor may not be unbiased) and I just pointed it out.
  30. William is outspoken, there is no doubt, but I'd agree with him about his software.

    I do work fulltime for Borland (I was also a speaker at BorCon) and I saw his work and I can honestly say it was impressive stuff.

  31. Disappointed[ Go to top ]

    I don't disagree with you.

  32. Disappointed[ Go to top ]

    I dont understand why people start turning against a company if they grow big.I understand developer community roots for the underdogs ; but its no reason to shit out a good product from a large company.
  33. App Server Market[ Go to top ]

    As I see it, there are many good J2EE products on the market. Having used a number of Application Servers, though certainly not all, I have formed a number of my own opinions on the subject, and I would not pretend to say that there is a definitive answer to the question of which is the best. For each project, the answer may very well be different. Some criteria for determining it may be (in no particular order):

    1) Longterm viability of the developer/product
    2) Ease of use
    3) Performance and scalability
    4) Adherence to specifications
    5) Cost
    6) Availability of extensions/services that are built on top of it (Content Management, Ecommerce, etc)
    7) Quality of documentation/support

    These are just a few criteria, and there could be many more. Just in writing this out, I can think of how, depending on what emphasis I give to each of these characteristics, my own view of the "best" might change.

    For our company, for example, we are creating products built on J2EE technology. We try to build them in a manner that is vendor agnostic so that our customers can decide for themselves what product they want to use. We would have recommendations for those who already do not have a vendor (perhaps along the lines of "free", "low-cost", and "high-cost"). For our purposes, adherence to the specifications is probably the most important criteria in evaluating an app server, and thus, of the ones I have looked at, BEA and Orion have done very well, while a product like Bluestone I have been less satisfied with(though I have seen they are improving).

    This is a long way of saying that comments like BEA sucks are silly. The people that make comments like this, I would encourage to elaborate on why they think this(I certainly have found myself saying this a couple times in the process of working with it, though it certainly would not be my final analysis) so that the rest of us can learn something from their experiences/knowledge.

    As for the Application Server market, I think that it will not be just BEA and Websphere, though they may dominate(perhaps with one other player). I think there will always be room for open-source solutions as well as some lower-cost vendors. Will there be 30 or so of them as there are now? No, but there will certainly be more than two. I don't believe J2EE will suffer from having a weeding out of the vendors. No one in my mind has such a great product at this point that it would be a great loss to lose them, and it would cut down on the confusion experienced by those looking at the market for the first time, who might be intimidated away from j2ee altogether because of it. One thing I have always thought that microsoft has going for it is that though they may not have the latest and greatest technology, they do tend to have simple unified message and platform, one that a person can wrap their mind around with a minimum of effort. Now I can tell from the comments here that everyone in this forum is a genius (-:, but there are many people out there who are not, and the most important thing is getting something that works, that their developer can work on with relative ease, and is not going away anytime soon. At the end of the day, most software is about facilitating business, and many of the distinctions we developers make and spend time arguing about are simply not cost effective. Is this to say they don't matter? No. I think they matter, even if only to satisfy my own personal aesthetics(though also for at times for business reasons), but I don't know that they would matter to me if I were the CEO of a company trying to decide on a platform.

    Other views/replies are appreciated.

    John Kelvie
  34. App Server Market[ Go to top ]

    I agree with what you say regarding corporate decisions.

    It is very difficult to make a case for those app servers.

    What do they bring to the table ?

    A big bag of possibilities. Look at possible ways to create an application (is the presentation in a JSP where data is taken from a bean built by a servlet, is there a templating engine called from a servlet, is there a WebGUI support tool used, is there XML/XSL ?) Just on this we are shooting ourselves in the foot. Look at what MS did with the SmartLinks and the possibilites they give in a unified way !
    And the VB-like way of creating web pages and all with a nice dev environment (Emacs is fine but not for everyone!)

    We are still fighting for the way an application should be structured and searching for the best (look at the ArsDigita ACS Java for some nice ideas).

    So, when will we have 'standard' war apps that we can weave together ? Not tomorrow!

    I think there will be more success with the stupid-SOAP protocol (one more simple and understandable wins!)

    So, for the corporate decisions, I would go to a player where the v4 of the server would still be supported in 5 years. Who can survive? A simple look at the financials of the small players gives us some insight.

    BEA is around for quite a while and a good product like WebLogic can always be bought over (hopefully not ala NetDynamics :-( )

    IBM is there to stay I guess.

    One choice is sure for performance : Go Oracle (and developers get it at $0)

    Good luck to the rest.

    For giving you some food for tought, have a look at what the perl community has as web modules... MP3 engines, Content Management, Portals, ... and mostly for free from CPAN.

    I also gave a try to things like Zope. This is the kind of kit we need for J2EE in standard form. Easy, nice, installable application through the browser.

    With that you can convince any CEO that the investment is worth the price and begin fighting for marketshare and money on the vertical you work in. Technology is there to enable the business to move forward.

    The worst thing is not to take any decision tough.
  35. "Species do not evolve toward perfection, but quite the

    > contrary. The weak, in fact, always prevail over the
    > strong, not only because they are in the majority, but
    > also because they are the more crafty."
    > Friedrich Wilhelm Nietzsche, German philosopher and poet.

    With regards to market share, whatever happened to Inprise/Borland as a CORBA ORB vendor ;-)

  36. If given a choice, I always do business with the little guy as long as he delivers an economical product. As we all know, competition is good for consumers. Please, don't jump on the BEA/IBM.

    Also, if I am not mistaken, Microsoft owns 25% of Borland. So, buying Borland is no better than buying BEA/IBM.
  37. ORBs all from Iona?[ Go to top ]

    BEA and IBM Vlad, IBM has it's own ORB inside WAS. Agreed that BEA still have some catching up to do before their IIOP implementation is on par with the T3 stuff. I guess we'll see them doing this as they move towards J2EE 1.3 where I think they'll need to bite the bullet and get on with it.

  38. ORBs all from Iona?[ Go to top ]

    This is the place where, leader are making difference. IBM using its own ORB implementation.
    BEA using its own IIOP (T3) implementation. Remaining guys r using IONA,Waltham,Boston's
    ORB Model. :)-
  39. ORBs all from Iona?[ Go to top ]

    The ORBs from these so called leaders will take years to achieve the same level of maturity as ORB from IONA.

    Vimal Kansal
  40. ORBs all from Iona?[ Go to top ]

    Give me a break!!! Iona never had much market share in the Java CORBA environment that was mostly Visibroker. With the CORBA market drying up Iona can't make much money selling CORBA so they needed to get into the server market. Unfortunately their first efforts were not promising. This is a difficult market and only the strong will survive. That's why BEA and IBM are making the grade.

    Do you really want a server that may not have future product development or support in a year?
  41. ORBs all from Iona?[ Go to top ]

    There was a massive overhaul of the RMI/IIOP implementation in WebLogic 6.1. This was both to support J2EE 1.3, as well as for interoperability with Tuxedo. I encourage you to check it out.
  42. Having worked with Tuxedo on a daily basis for 1.5 years, I can say that it is a functionality missing from J2EE.
    Having a BEA Weblogic/Tuxedo bundle would allow for really powerful applications. This is what I would pick as five star choice. Why is Tuxedo not given with Weblogic ? Or this M3/Iceberg OTM ? EJB is just distributed components ala COM+ we have for free from M$. CMP/BMP? Who needs that? Even EJB, they cannot scale if not supplemented by something like Tuxedo (queues in front of services, FML rules, simple to use publish/subscribe, clustering in the blink of an eye...) What the enterprise needs is this Hub and Spoke approach explained by McKinsey some years ago. So far, no sound in that direction from J2EE...

    On a side basis, we have done an application with WebSphere... quite difficult to have something without problems (especially on the appserver level where we asked for patches since security was very weak -- e.g. predictable session keys - a cracker's dream!)

    Also, starting very slowly (nervous breakdown if you really need it up and running quicky).

    Administration interface slow as hell, not always doing what it needs to. In that respect, BEA is much much better.

    Still IBM was very responsive for support calls and gave us insight.

    So, best for me : BEA <production>/Orion <low cost alternative> / JRun <development, it is free and gives you nice icons to do a quick restart> / Tomcat <to see what is going on on the front line> / J2EE ref impl <to learn J2EE>

    Best for my pocket checkbook : IBM WebSphere
    Good for application building : IBM InfoCenter and docs

    Good frameworks for thinking : Turbine from Apache
    Alternative thinking : ATG nucleus, ArsDigita Community System

    Still I wonder why OTMs are not commonplace today.

  43. I think you've hit one of my own subjects here. You're right, of course. Encina or Tuxedo are the way to go for easy serious scalability. You can't beat up front queueing for easy scalability/failover.

    Maybe, now that J2EE servers will arrive with message beans, people will begin to realise the benefits of the messaging approach.

    The funniest thing I've seen on the web in a while was Bill Colemans key note at BEA World this year. He spent around 20 minutes talking up WebLogic's scalability and then brought on a lady from VISA as proof. And guess what, VISA didn't use WebLogic, they used Tuxedo, a non OO 10-20 year old technology but who can blame them, it works and is the obvious choice for this sort of thing.

  44. As far as scalability goes with Tuxedo we were able to support a call center with 1500 people and around 600 simultaneous users on an Oracle database on one HP9000. Running queries all around and even doing a lot of screen scraping on tons of screens. Tuxedo is for the enterprise stuff and let's add a front end with web tech...
  45. J2EE? more like J2WE[ Go to top ]

    Yep, couldn't agree more.
    I said it before and I suspect I will say it again - the E for enterprise in J2EE is simply wrong.
    J2EE is great for doing web applications and putting web facade (be it UI or service-like) on a system, but is still missing a lot that real world enterprise application need.
    Well, just have a look at what's the official example - a B2C application.
    What I see now here is that people put away plans to do their .com type projects but keep doing their core enterprise systems. Hopefully, people responsible for the J2EE spec will take this into account and start doing something to help them - because they haven't done that much yet (at least in comparison with what was there before). Personally, I worry about that more than what vendor is currently at the top.
  46. iPlanet Enterprise Edition comes with Encina which is used by it's EJB container for handling distributed transactions.
  47. iPlanet Enterprise Edition comes with Encina which is used by it's EJB container for handling distributed transactions.

    So does Iona's iPortal Application Server (enterprise edition). It comes with an Encina transaction monitor, wrapped as an OTM, that can be used by the app server as well as other CORBA applications.
  48. The Enterprise Edition of the iPortal Application Server is using JTA over OTS (IONA's CORBA Object Tx Service) for XA interoperability. This even allows to do thing like full distributed JTA/OTS transaction accross EJBs using a local Oracle and an IMS OS/390 transactions may be calling to DB/2.


  49. Why is Tuxedo not given with Weblogic ?

    Check Weblogic Enterprise WLE, it comes with Tux included...
  50. Last time I checked , WebSphere was not built using IONA's version of CORBA? WebSphere is built on IBM's Component Broker, there own version of CORBA.
  51. At current prices cost of the app server is insignificant compared to the cost of development, maintenance, training of support staff, etc. "Extras" are also not what's needed - what you need is a solid, bug free platform that does the basics well.

    Yet the managers who make decisions about buying J2EE app servers don't know what are the basics that need to be done well, and what are extra bits of frippery. Add in what seem to be a fair bit of blatant lying in the marketing hype of most app servers, and journalists writing reviews who seem to believe whatever the app server manufacturer's press release says, and it's a bit depressing.

  52. I did not use the word 'dwarfing' in my original post but this does raise an interesting question about market share.

    I have a feeling that the market share attributed to BEA and IBM is not altogether accurate from a J2EE developers perspective.

    I suspect that much of this is attributed to simply WebServer deployments and that not many of the organizations using these products are using EJB/Messaging/Connector technology. These applications probably consist of JSP/Servlets with some JDBC Connection pooling. Some of the deployment relate to old technology predating ejb 1.1 never mind ejb 2.0.

    When it comes to deployments utilizing the whole of J2EE I suspect they are not dwarfing as much as people would have you believe.


  53. I don't think that market will be ruled by only BEA or IBM. Just look around, you will find that so many better implementations with better performance have come up. The one that comes to mind is IONA's Iportal Application server. In some of the independent benchmarks by third parties it has beaten the appservers from BEA and IBM by a huge margin in terms of performance, tools , ease of use and the price. I think the competition is only going to heat up and nothing could be further from truth that J2EE will be governed by IBM and BEA alone.

    Vimal Kansal
  54. This is true.
    Why only BEA and IBM are only capturing market share more and more now a days.
    1. Slow down of economy.
    2. Aggressive development capabilities to implement the specs as and when they released. That&#8217;s what BEA is doing.
    3. Need to have a sound back ground and strong marketing capabilities.
    4. Now a days, customers are very choosy to buy a product. They are looking at brand and market analysis. (Most of the hype is going beyond IBM/BEA.)
    5. Other guys are not showing any great characteristics or not differentiating their product with other ones. Only thing they show is COST.
    6. Oracle - major giant it self failed in producing an app server and depended on Orion.
    7. Only two types of customers are there for J2EE: POOR or VERY STRONG.
    8. POOR companies are going beyond JBOSS/ORION (less cost APP Servers.)
    9. Major Companies (Customers) in theirs production going for either (MOSTLY) BEA OR IBM.
    10.And LION (Microsoft) always sitting readily and waiting to eat any thing. Few guys like BORLAND trying to put their legs on both.
    11. iPlanet - to the name it is a product but internally totally depended on apache open source.
    12. There is no other true caliber guy to give competition to these two big bulls.
    If u continue like, so many things..........

    J2EE --> just 2 End of Enthu.

  55. I think the view that only stuff coming out of BEA or IBM is the real stuff and others are churning out is crap is a rather myopic one. I have worked with most of these appservers and I can state with utmost confidence that we do not have to buy this opinion. Just look at BEA they have some propreitry stuff build into there appserver. Sam applies to IBM. iPlanet migh have come from the company which is spearheading the J2EE but it represents merely a patch up of some technologies like Netdynamics etc which Sun bought.Somebody has raised the issue of price. I think unless one is suffering from the mentality of "costlier the product, better it is", it is always prudent to look at price issues. Its like a rat race, sometimes somethings become fad and we all start following it without even giving a chance to alternatives.
  56. Opinion: J2EE = Just 2 End of Enthu..[ Go to top ]

    BEA's weblogic is the best app server in the market.
    No doubt that companys are buying this server
  57. I do not think that other application servers will fizzle out due to the headway being made by BEA and IBM. However I think there is a considerable risk of some smaller players being competed out of the market to the extent when they will either stop making application servers altogether of focus more on other aspects of their business.

    In addition lets not forget the pressures put on Architects by non-technical decision makers to choose a certain server. If the two players in question keep pulling away the pressure to go with them for large development projects will surely increase.

  58. <quote>
    I suspect that much of this is attributed to simply WebServer deployments and that not many of the organizations using these products are using EJB/Messaging/Connector technology. These applications probably consist of JSP/Servlets with some JDBC Connection pooling.

    It would be really interesting to see an analysis concerning the actual use of J2EE features in app server environments. I expect an overwhelming part of J2EE app server installations to be used as web application servers (I would not call those "web servers", though - they are "web application servers", consisting of a web server and a J2EE web container).

    JSP, Servlets, JDBC with connection pooling .. probably proprietary/self-developed frameworks inbetween ... but in a lot of cases neither EJB nor JMS. I expect this scenario to be dominant in software products based on J2EE, this is probably different in inhouse solutions based on J2EE.

    But for such J2EE web application products, why would anyone buy heavyweights like WebLogic / WebSphere / iPlanet Application Server or suggest either of them to their customers? Of course, there could be political reasons, but could there be technical reasons? There are far better suited J2EE servers for web apps, like Resin from Caucho (my favourite, 500 USD per server) or JRun (the Professional Edition, about 800 USD per processor). You could even use Tomcat for lowest cost installations.

    Another interesting candidate is the recent release 6.0 of iPlanet Web Server (1500 USD per processor, not to be confused with the totally different and very expensive iPlanet Application Server). iWS 6.0 is a full-fledged web server based on the former Netscape Enterprise Server and includes a J2EE web container (Servlet 2.2 and JSP 1.1) that is tightly integrated into the web server itself.

    So if you want a J2EE web app server with sophisticated web server features and/or full remote administration capabilities - take iWS. If not, Resin with its integrated no-frills web server is IMHO the better option because it is so extremely easy to install, configure and handle - and significantly cheaper, especially on multi-processor machines - and developer open source. And you can always use Resin as a web container behind your favourite web server.

    And according to my experiences, portability of J2EE web apps is no problem at all - quite in contrast to EJB apps. Our main product uses JSPs, Servlets, JDBC and an inhouse-developed middle-tier framework inbetween - in total >1000 classes. Running it on all of the above mentioned web app servers and even switching between the various app server installations on a machine is absolutely no problem and requires only minimal server-specific configuration overhead.

    So I absolutely agree with the majority of opinions presented in this thread: There is a market for J2EE app servers other than IBM's and BEA's, especially when talking about the common case of J2EE web applications that only need a lightweight J2EE web app server.

  59. Hi Will,
    I guess my posting in the Borland news item prompted this so let me just say as quickly as possible why I think this will be the case.

    A J2EE server requires a significant investment for a customer to deploy it, we're talking millions of dollars in most medium to large companies. They train data center staff, helpdesks for developers, they develop procedures for deploying applications, integrate it with existing corporate standards (directories, security, existing middleware etc), you get the picture, it's a lot of work.

    Once a customer makes a decision to adopt a J2EE server then it becomes a requirement when new middleware products or third party J2EE applications are examined by the customer. The customer is happiest if the new middleware lets him leverage the considerable investment that he's already made by adopting the J2EE server.

    It's clear now that 40-60% of the J2EE CPUs being sold are either BEA or IBM. A lot of these companies are the big shops that all the vendors want who also have the money to buy J2EE components/applications/middleware moving forward.

    Nearly all J2EE vendors are developing their value add stack on their own servers. Selling these stacks (and some are very good) on their own servers only is a liability. It's a mark against them when they try to sell it to a customer thats already adopted another vendor.

    Given that J2EE servers will become very commoditised over the next year and half and accordingly pricing will be pressured then it becomes clear that what customer will still pay premium prices for is middleware that does something else.

    Lets take a smaller vendor that has say 8% of the J2EE market. They make a great piece of middleware on top but only sell it on their J2EE server. Why only sell it to 8% when you could sell it to 100% of the market.

    By all means continue to put money in to your J2EE server but for me, if I was a shareholder, I'd question this business decision in terms of potential return on capital invested when compared to the return on the layered middleware. I think SilverStream were the first to start to hedge their bets with a strategy like this.

    I say that Will and Jon Weedon from Borland were recently 'ribbing' Cedric Beust from BEA about the stock CMP with WebLogic. Well, I don't think it's enough to make people run out and dump WebLogic and buy Borlands product but I do think that given WebLogic customers need to buy a CMP product in any case, why don't Borland sell your CMP container to WebLogic customers if it's so good.

    In the same way, I look at Persistence. They, for me, (and Will, I have actually used the product ;-) ) have the fastest CMP implementation on the market. It's just so fast. But, it doesn't matter. I don't think they will survive. But, if they resold the CMP container on WebLogic/WebSphere etc then maybe they will survive given the weaknesses of the WebLogic. It's a definite value add that can be demonstrated and lets the customer leverage an existing investment. Seems like a better case than 'dump your existing investment and buy ours because this month we're better...'.

    I would like to see the J2EE market standard to practise what it preaches and componentise the J2EE server. I buy my basic J2EE infrastructure (JTA, session beans etc) from BEA. I buy my JMS and CICS/IMS JCA adapters from IBM. I buy my CMP implementation from Persistence and my event broker from Sybase but the underlying basic J2EE server lets me as a customer leverage the significant costs of deploying it over all these extras.

    I look at J2EE now like Windows and GemDos were 15 years ago. The money in the future for software companies at the time wasn't in developing operating systems, it's the applications and utilities that would bring them their fortunes. Anyone that stayed in the operating system market was crushed. I think it's the same for J2EE in the near future, like it or not, it's time to smell the roses...

  60. I say that Will and Jon Weedon from Borland were

    > recently 'ribbing' Cedric Beust from BEA about
    > the stock CMP with WebLogic. Well, I don't think
    > it's enough to make people run out and dump WebLogic

    Especially when the feature we were discussing has been requested by close to none of our customers :-)

    Every container vendor with a little bit of common sense is moving away from implementing locking inside the container anyway (and the most recent to have realized this is JBoss).

    Other than that, I agree with pretty much everything else you say, although I'm sure the Inprise Special Unit will quickly jump on me and accuse me of being biased :-)
  61. Tech reply[ Go to top ]

    This post is purely a technical one - based on a little comment by Cedric (@ BEA.com) and I am responding to it:

    >Every container vendor with a little bit of common sense
    >is moving away from implementing locking inside the
    >container anyway (and the most recent to have realized
    >this is JBoss).

    How do you explain the fact that WebLogic (until version 6.x?) has pessimistic locking at the container level? Your snipes at Borland aside, from your own comment, it seems to me that common sense (to use your very own words) came to BEA only 2 years (or is it more?) after your first EJB product offering.

    I'm now working for Borland as a consultant - since the last two weeks - but I should mention that in my previous job (2+ years), I worked primarily with WebLogic 4.x.x & 5.x before selecting another vendor (no guesses there).

    Btw, Cedric, on a technical note - there is difference between pessimistic locking at the container level and at the database level.

    For the uninitiated, pessimistic concurrency at the container level is usually provided by serializing access to just a single instance of an entity bean. IMO, this is not scalable (obviously, concurrent transactions would have to 'wait' to get access to that one and only instance) and in a cluster, this solution obviously would not work. WebLogic (pre 6.x) works this way. Cedric - correct me if I am wrong.

    You can implement true serializable isolation by using database locks (locking pushed to the database instead of container). In many SQL 92 compliant implementations, this is done with a "SELECT FOR UPDATE" syntax (e.g. Oracle). An alternate solution - instead of using pessimistic concurrency at the database level - is to use optimistic concurrency at the container level to 'simulate' serializable isolation at the database level:
    e.g.: UPDATE some_table SET (new_values_for_cmp_fields) WHERE all_cmp_field_values_are_values_read_in_at_start_of_transaction

    Cedric: Does WebLogic have either (i.e. database locking? or verified updates?)? Or rather, how does WebLogic guarantee true serializable isolation semantics with a database like Oracle - using CMP?

    PS: Cedric if you use your line (below), then obviously I cannot respond. Maybe in that case (as someone mentioned earlier), market share is (more) about WebServer/WebServices.
    >the feature we were discussing has been requested by close
    >to none of our customers :-)
  62. WebLogic CMP = TopLink[ Go to top ]

    Before this turns in to a Borland vs BEA fisty cuff :-)

    Maybe the reason no customers have requested such a feature is that anyone using WebLogic with CMP buys TopLink. If hardly anyone uses the builtin CMP and I think this is the case then I think this puts Cedrics comment in context.

    Maybe Cedric or someone from BEA can comment on whether this is true or not.

  63. Next challenge[ Go to top ]

    What can I say -

    Read this and see if you are one of EJB
    developers/architects who are idiots and
    the rest are pig-headed.


    I tried to post this article as a new topic - however,
    I think theserverside gave a no-go on this topic.

    Tieu Chu
  64. Next challenge[ Go to top ]

    I'm from BEA, but I don't want to get flamed, FUDed, or any other type of fisty-cuffed. I just want to answer the question at hand.

    In WLS 6.0, we offer container locking or database locking. With database locking, you can set the isolation level of the DB appropriately and the container will detect collisions where appropriate. We support Oracle's SELECT FOR UPDATE syntax in the container natively.

    As an FYI, we've seen that for the most part TopLink was heavily used on the WLS 5.X platform, but with the introduction of WLS 6.X, we are seeing many more production implementations that are using our container natively because of EJB 2.0. EJB 2.0 CMP semantics allow the container to do different optimizations under the covers that provide for significantly better performance over EJB 1.1.

  65. Re: Next challenge[ Go to top ]


    As an FYI, we've seen that for the most part TopLink was heavily used on the WLS 5.X platform, but with the introduction of WLS 6.X, we are seeing many more production implementations that are using our container natively because of EJB 2.0. EJB 2.0 CMP semantics allow the container to do different optimizations under the covers that provide for significantly better performance over EJB 1.1

    I do not intend to flame/FUD at all :) But considering the fact that EJB 2.0 is still in its (second) proposed final draft, don't you think it is rather immature for BEA to recommend a EJB 2.0 (still non-final spec) based solution. And it will be quite a while before any vendor (including BEA) is certified to be compliant.

    Of course it is nice that people get to 'play' around with or preview the offerings of an upcoming specification, but recommending that development proceed [into production systems] (as you mention - see quote) based on a *non-final* spec is something most customers will not want to hear (I would love to hear something to the contrary). The changes to EJB 2.0 PFD 1 might serve as a reminder.

    And you mention that the upcoming EJB 2.0 semantics allow a container to do different optimizations. But of course nothing prevents a sophisticated EJB 1.1 implementation from doing the same (a few quality implementations stand testimonial to that). And besides the 'limitations' (in EJB 1.1) people mention which the upcoming EJB 2.0 has removed - are not really limitations at all - just that the upcoming EJB 2.0 spec has made the model more explicit now.

    But ah well ... how so convenient it is to blame the spec (instead of the product ;)

  66. ASK BEA[ Go to top ]


    Could you tell me how the following is implemented.

    "In WLS 6.0, we offer container locking or database locking. With database locking, you can set the isolation level of the DB appropriately and the container will detect collisions where appropriate."

    Is the following sentence the detection(?) mechanism.
    "We support Oracle's SELECT FOR UPDATE syntax in the container natively."

    I have an example which I would like to present to help me understand what your containers cmp engine does if the above is not the case.

    We have 2 transactions running, t1 and t2. Both transactions will attempt to update the same record after an initial read. Lets say that t1 originates from an ejbcontainer and t2 is a legacy system. Here is the tx history.

    t1: select x from mytable where id=1 (x=8)
    t2: select x from mytable where id=1 (x=8)
    t1: update mytable set x=10
    t1: commit (x=10)
    t2: update mytable set x=11
    t2: commit (x=11)

    Can you tell me if this can occur using your product and Oracle?

    From my previous experience with Oracle the only locking that will occur will be during t1's update and t1's commit. In Oracle when a tx modifies a row its tid is added in the txlist which is located in the blocks header. The row header is then pointed to this tx through an ITL entry. Locking on this row will occur between this change and the commit call. Any tx that attempts to modify the row during this time frame will be blocked until the tx is commited.

    William Louth
  67. ASK BEA[ Go to top ]

    One correction the update statement should have had " where id=1"

  68. ASK BEA[ Go to top ]

    Why are different users updating the same rows in the database? Do you have a real-world need for this? Personally I have never seen a need for record locking. If you have multiple users updating the same records, there is a problem with...

    1. your business process
    2. your database design

    Please, show me an example where there is a need for this. Too much time is wasted discussing the "database locking" issue. Design your database correctly and database locking is irrelevant.

    Jeff Cunningham
  69. ASK BEA[ Go to top ]


    In the telecommunications and banking industry not everything is accessed by an 'user'. This would be so nice and make life easier for some designers but this is not the case. I did mention legacy systems in my initial posting.

    You are correct in that it is possible sometimes that the problem can be simply solved by business process or database re-design. But in my experience getting both of these to change is a very hard task especially when you are coming in with some new technology.

    I have worked on some gsm billing engines where I have been frightened by the poor level of design both in terms of its engine and database design. Its has been a nightmare trying to tie in other systems (credit checking, services provisioning..) and support the development of new business processes. Its impossible to control them all and attempt to reduce collisions.

    To be honest my point in bringing this up was motivated by my recent visit to the edocs.bea.com website. I had a look at some of the cmp engine "new features" and it has to be said that Borland AppServer and some others vendors had these features sometime back and at the time these were made available I had BEA sales people telling potential customers that these features were over-rated.

    I am not here to knock the sales people, their just trying to sell a product, but do you not wonder if it was not for the other vendors in the J2EE space would these features be shipping today with BEA WebLogic. These vendors have contributed to the specifications which has benefited us all not matter what appserver you have a preference for.

    We need more competition or J2EE will reach its limit prematurely.

  70. ASK BEA[ Go to top ]

    You make a good point about supporting legacy data.

    This has been a very enlightening thread. I'm downloading Borland AppServer today. Thanks for the information.

    Jeff Cunningham
    Bareback Development Corporation

  71. ASK BEA[ Go to top ]

    I think so long as we have the current monolithic approach to J2EE servers then nothing will change. Most of the discussions on the thread seem to be centered around CMP. The fact that people are choosing J2EE servers based on a CMP implementation is nuts to me.

    Developers should be able to buy a J2EE server and use what ever containers they want with the server. I may want to use a Borland CMP container because it's wonderful, I may want a ODBMS based CMP container for my green field persistence needs, I may want to use a vanilla message bean container like the one in WebLogic 6.0, I may also want to use a third party message bean container that supports DSM for very high availability. Horses for courses.

    The point is that currently J2EE vendors seem to expect that their container implementations are appropriate for all applications. This is clearly unrealistic and I think that customers need the flexibility to pick and choose container implementations. We need standards for pluggable containers. If we have this then if Borlands CMP one is so good then people can use it as a choice with WebLogic is thats what the company standard is.

    I think this is an area that the J2EE spec currently doesn't address at all although there are a couple of JSRs that may help here.

  72. ASK BEA[ Go to top ]

       In the example you have shown above, what would you consider to be the appropriate manner to handle such an occurence? I am curious how one would deal with such a situation.
       One possibility would seem to be to lock the rows at the point when they have been selected...another would be to force legacy systems to interact with the database through ejbs. Would you consider either of these good answers? Is there another answer that is a better approach?

  73. ASK BEA[ Go to top ]


    The Borland AppServer CMP engine deals supports optimistic concurrency by checking the values read in at the start of the transaction match the ones existing in the record when the update is performed. You can verify all fields or simply those that have been changed (VerifyModified). This is simply done through an update with a where clause containing conditional expressions for the fields in question and values. In my example "where (id=1) and (x=8)"

    The VerifyAll fields would typically be used where there was some form of a constraint between a number of fields which might not always be updated together.

    This verification mechanism will result in t2 being rollbacked.

    Again, Borland AppServer has had this for some time. Sysbase EAServer has recently announced support coming in their next release.

    Note that Select For Update and Select For Update with Wait is also supported within Borland's cmp engine.

  74. ASK BEA[ Go to top ]

    Select For Update with Wait

    Is it select for update nowait ?
  75. ASK BEA[ Go to top ]

    Yes. Thats the problem with sending posts at 3.00am.

  76. ASK BEA[ Go to top ]

    Just one last posting today (I assume everybody is getting tired of this thread). I have gleaned alot from this and it seems to all boil down what a previous boss (when I left college) always said 'What is good? Its all relative'.


    Regarding your comments on having most of the services plugable so you could switch to a cmp engine like Borland&#8217;s. I think if we could get all AppServer&#8217;s implementations to be able to interoperate that would be especially helpful both to developers and the up and coming J2EE container vendors.

    I was just recently in with a large financial corporation which has the 2 leading appservers already in operation and they have now decided to try and move too Borlands AppServer. You would expect that in the meantime there might be some period where they would like different appservers (beans) to communicate (transition). The last time I attempted this it was not possible. I know at the JavaOne that some vendors did show some level of inteoperability but unfortunately one of the leading vendors did not and this bank has this one.

  77. last post[ Go to top ]

    Personally, I thanks everyone for participating
    this thread - and give me invaluable comments on
    all leading appservers( BEA, IBM and Borland)
    for their technical perspectives.

    Tieu Chu

  78. ASK BEA[ Go to top ]

    I don't think we'll see true interoperability until the late 2002 at the rate things are going.

    I can probably guess what the leading server was that didn't interoperate.

  79. ASK BEA[ Go to top ]

    Excuse my ignorance of this subject, but I am unfamiliar with some of the aspects of the situation in question.
    Is this assuming that both transactions are occurring through an EJB? If the legacy system is accessing the database directly through JDBC/ODBC or some other means, I don't see how it would know to roll it back.
    Also, when it rolls back does it throw an exception or by some means allow the user to know that their transaction has been disallowed?

  80. ASK BEA[ Go to top ]


    Assume (t1 = legacy and t2 = ejb) OR (t1 = ejb and t2 = ejb). Sorry, cannot talk more am I trying to get my product through QA.


  81. ASK BORL[ Go to top ]

    Borland has an app server? ;-)

    I'm just kidding. I'm just kidding. I've heard that it is quite handy for development and debugging.


  82. ASK BEA[ Go to top ]

    I have faced the same scenario in my project and I have used "SELECT FOR UPDATE" to handle the scenario. Is there any better option to handle this?

    Another problem we have faced.We are using WL5.1 (JRE1.2) .Our client is using JRE1.2 also. When we tried to use WL6.x we faced a scerious problem - JRE1.2 compliant client cannot communicate properly with WL6.x server. I can give the brief details of the problem.

    I am calling a method of my bean which returns a String (XML doc) . When the size of the String is exceeding 60 KB it gives the stream corrupt exception.

    Though it was written in the BEA site that JDK1.2.2 client can communicate with Weblogic6.0 server , still it hasn't worked properly. I have contacted BEA for this problem. There response was -

    CASE_ID_NUM: 236622
    Hi Srijeeb,

    thanks for letting me know.

    Unfortunately, just as it's stated in our document web site,
    "... it is possible to connect to client using 1.2 jvm...", but
    we are not supporting this situation.

    Sorry it's not the answer that you are expecting.
    But we really recommend to have both client and server
    using a 1.3 jvm.

    Please let me know how you'd like to proceed with this case.
    Thanks & Regards,
    --Renqi Li
      BEA DRE]
  83. ASK BEA[ Go to top ]

    See http://java.sun.com/j2se/1.3/docs/guide/serialization/relnotes.html

    Strings longer than 64K can now be serialized (since 1.3)
    Prior to 1.3, an attempt to serialize a string longer than 64K would result in a java.io.UTFDataFormatException being thrown. In 1.3, the serialization protocol has been enhanced to allow strings longer than 64K to be serialized. Note that if a 1.2 (or earlier) JVM attempts to read a long string written from a 1.3-compatible JVM, the 1.2 (or earlier) JVM will receive a java.io.StreamCorruptedException.

    Also note that this thread is for BEA bashing only, you should post questions like this to the 'Discussions' section ;-)

  84. ASK BEA[ Go to top ]

    Hi Dimitri ,

    Thank you for your explanation but I have already got the answer from some different source.Actually my intension was not to post a problem and excpecting answers. My intension is to tell that what BEA demands ( may be it is applicable to other J2ee container provider , I don't know as I have not worked in other env)is not always true. I could have posted my opinion in some different way (without giving such details ), but then some of the threads may be generated form someone else as some of the participents in this thread is from BEA. Then again I had to provide the details.Hope you will understand.

  85. Next challenge[ Go to top ]

    Hi Tieu,

    I agree with a lot of what that article you referred to says. Before I say anything. I work for ATG. (Which by the way has been practising a lot of what that articles preaches from day one. That is why Sun uses it anyway). The trouble with most Java Developers as that article rightly points out is that they come to Java with a traditional 'C' or write monolithic code approach. No awareness or knowledge of MVC type approaches to development. Worse still, a lot of developers do not realise that J2EE means you've got to wear an "Architectural Hat" most of the time. They think all they have to do is write the code as long as its Java. Unfortuately, this is not good for the recipient companies. I've seen some designs that will make you weep. Anyway never mind my main point is this. As long as developers, companies, whomsoever, allow themselves to be hoodwinked by the two big Gorillas in BEA and IBM, the worse it is for all of us. None of us have a right to critize Microsoft if we allow the J2EE Market to go the same way MS squeezed everyone in all markets.

    The spec not only allow each vendor to innovate, it also allows us to use App Servers with a "Fitness For Purpose" Vanguard. Alas, what we have at the moment is that because of the downturn in the US, everyone thinks the two Gorrillas have won the battle, What battle. Whoever said App Servers mattered. The real deal is the Application Stacks you have on top. If this debate will continue in any form that is what you folks should concentrate on.

    Here are the basics tests I think you folks should consider,

    <1>Do you really use MVC design patterns on your projects ?

    <2>Do you build sites with Content in mind using TagLibraries, and avoid loads of Java Code mixed in your JSP pages. ?

    <3> Are you empowering your user to Dynamically Generate thier own content using CMS XML Template ?

    <4>Are you a extremist that thinks that you must write EJBs before you build a J2EE compliant application or site.

    <5>Do you keep reinventing the wheel from one project to another ?

    <6> Does the App Server you use give you excellent Container Managed Persistence, Caching, Database Abstraction, Goodies out of the box ?

    <7> Do your environment seperate content developers from page developers ?

    This is just food for thought. The whole point of J2EE as far as I'm concerned is to encourage us to build applications better with Architectural Patterns, Portability and COMPONENTS

    Finally, just a small plug if your Application Server does what this link does, you are doing very well indeed.


    Its about the application services running on top of the Application Server stupid, not the Application Server Itself!!!

    Cheerio Folks

    Michael Fasosin
  86. Next challenge[ Go to top ]


    You made your point. Your questions should be
    addressed in a new EJB book from Ed. Roman;
    my concern is that Ed's book uses BEA's WLS
    as an only appserver example.

    It's nice if Ed can add a chapter which compares
    *fairly* all major appservers out there.

    Tieu Chu

  87. Next challenge[ Go to top ]

    Ed Roman uses WebLogic for his book, because it refers to just what I tried to explain 3 threads ago (yeah, multithreaded environment ;-)), BEA is the only one on top of the J2EE specifications (And they are a big player defining these specifications too).
    At one point, who cares about the App Server, one should look at his company requirements and just take the "good" app server. ECPerf should give us some clue. If you are only a JSP/Servlet shop, should you pay for all the other extra stuff you don't care (JMS, JNDI, EJB) ?
    The main challenge is, now we have layed off (huu sorry: OUT) ;-) the foundations, to build something.
    The component market can be huge (if using any good SOAP server, you can bind a component to a Web Service, just for the heck of it), who has not coded a shopping cart in his life ? Or make use of a worklow engine on top of the J2EE app server ?
    J2EE is a framework so it makes sense to make design decision early on. It binds the developers in a mold.
  88. Next challenge[ Go to top ]

    Re: Mastering EJB 2.0 book. We will have a mechanism for providing examples that run on other platforms that support EJB 2.0. BEA WebLogic Server was the low hanging fruit, but we understand that ubiquitous support of the examples provided in the book is key to understanding the true nature of EJB 2.0. We'll be announcing how this will take place when the book is released shortly.

  89. Tech reply[ Go to top ]

    Does WebLogic have either (i.e. database locking? or verified updates?)? Or rather, how does WebLogic guarantee true serializable isolation semantics with a database like Oracle - using CMP?

    We have "database" locking: locking is deferred to the database (which can be optimistic or pessimistic, Oracle uses optimistic by default).

    I don't believe that optimistic locking at the container level is very useful, you are welcome to dig the ejb-interest archives if you want some more details on my position (just a personal opinion), I'd rather not repeat everything here.

    Thanks for the other good technical points.


  90. I agree with you entirely and if one ses that Gemstone has recently stated that it wishes to leverage its PCA technology to provide caching solutions then one can see the validity of your argument
  91. iPlanet...why doesn't anyone give iPlanet credit for more market share? Everyone I know uses iPlanet and with the upcoming releases, I expect it to challenge for the top spot. It really shines on Solaris and some of the larger shops who have been successful are using it.
  92. There is plenty of room in the market for any software vendor that puts out a quality product....

    Bluestone - (before HP) expensive (over 100k) and buggy

    Tomcat - needs an integrated web server

    Enhydra Enterprise - not sure if this product will ever appear in a production form

    Orion (a.k.a Oracle 9iAS) - solid product, horrible product support (from the IronFlare company...)

    iPlanet - no personal experience, but from people I have spoken with, this product is VERY buggy

    BEA - haven't tried it yet

    Websphere - haven't tried it yet (the new release is suppose to be very stable)

    Blazix - new kid on the block, could have a future

    JBoss - a great product, although when I tried it, the installation was a bear to install and their mailing list was of no help

    There is alot of software vendors out there, and I'll bet there are 2 nerds in a garage right now making the next generation Java App Server that will blow everyone away....
  93. There are at least 2 distinct markets for J2EE app servers. The first is enterprises buying for inhouse development. This market doesn't care about portability and is not especially price sensitive. This is the market IBM and BEA dominates. The second is software product companies developing on top of a J2EE app server. This market cares a lot about portability and is price sensitive. In my experience the last thing these companies want is to be locked into a high price application server vendor. Websphere works with IBM's other offerings - IBM is THE integrated stack vendor. Lock-in is unavoidable. BEA is trying hard to go down the integrated stack route. While it talks about being standards compliant. BEA works hard at obscuring where the standard ends and their proprietary extentions start. This makes BEA an unattractive option for software product developers.

    When J2EE applications start shipping in volume we will likely see a substantial shift in market share.

    The second force at work is commoditization of the app server market. This is an inevitable result of standardization.

    JBOSS will inevitably gain substantial market share. BEA will I believe loose substantial market share - Its business model will have difficulty coping with commoditization. IBM will be relatively unaffected - Ditto Oracle and Sun. I also predict Borland will do relatively well as its business model is not particularly impacted by commoditization and it is getting its app server into the hands of developers via JBuilder.

    Phil Bradley
  94. BEA works hard at obscuring where the standard ends and their proprietary extentions start. This makes BEA an unattractive option for software product developers.

    I don't agree with you Phil. I beleive BEA was quick in supporting standards and Hence and an "Attractive" options for Software Developers.
    Undoubtedly BEA is #1 choice as far as developers are concerned.

  95. I share the fear J2EE AppServers takeover,

    The comapnies which will be able to offer better integration with existing Enterprise components (middleware, databases, legacy systems) will win the battle.
    Both IBM and BEA has it, Oracle will soon have it and i think the three will rule the J2EE App-Server.
    I think other companies can still make the buck, but only by implementing supplements, non-spec additions such as data-caching.


  96. Guess the 2 big players will not stay there for a long time because, as someone stated, there are two different markets for AppServers, the "in house development" (dominated by Borland and BEA) and the "standard software" market (which has still to evolve regarding J2EE).
    Additionally, I'm not sure how "dominant" BEA and IBM are really:
    *) They both offer(ed) sort of a WebServer (JSP/Servlet engine)... okay, I don't count this as being in the J2EE AppServer market
    *) Who knows how many companies use Borland AppServer? A license comes with every sold JBuilder...
    *) Who knows how many are using jBoss, Orion? Free versions available
    *) How many WebLogic/WebSphere licenses were bought and just thrown away? I have seen this quite often!

    So I doubt the statistics...

    Additionally, people doubt portability at the moment. This will change, maybe with J2EE 1.3 and as people prove applications can be ported easily (we recently switched AppServer in quite a large project). You can now choose the best server, and companies are indeed beginning to do this. Slowly they are beginning to listen to the developers, as they understand what they are doing (at least here in europe ;-)
    Well, and what about the appservers themselves?
    *) IBM has managed to get a real J2EE server to the developers... WebSphere V4 looks promising... but well, even 3.5 looked promising before I used it *gg* Seriously: V4 seems to be ok, although there are better servers
    *) Who chose BEA for stability?! (I saw this within this thread). This must be a joke, BEA is everything else than stable, 5.1 was ok (although a simple exception could crash the server, well the webserver part), 6.0 was a real joke and 6.1... we'll see. Alltogether I must say I dislike BEA, appserver is nice, tools are crap (provided the tools even exist), server crashing, console a joke,...
    *) Didn't use iPlanet, but I heard it is very fast although somewhat buggy, heard it has some really serious bugs (crashing the whole cluster)

    The two players I hope will be getting more market share are
    *) Borland, because their appserver is the best piece of software in this market (IMO). I know few people who tried BAS and didn't like it.
    *) HP with Bluestone: This product is also quite good, and sure HP is pushing it. Someone said HP had no luck with software, well, they are 4th? 5th? Not sure, but among the top10 of biggest software companies (before bluestone). It is especially good for real large-scale deployments (look at their references).

    Okay, well, we'll see.

    kind regards

  97. Bernhard,

     I doubt you really worked with Weblogic. My current project(Live and being used) in production and Downtime (related Crashes you are talking about) is 0%. We are on wls5.1.

    Can you tell me your real experience with WLS and why you claim it to be buggy!

    Stop spitting on a mountain just because it doesn't care!!
  98. BEA doesn't suck, far from it. But it is also not the only or best solution, depending upon how your project requirements stack up (the list presented earlier was a good example). I hope BEA and IBM continue to slug it out at the top each with their 30 odd % market share (or whatever it is, its not that important). But what I really hope is that the J2EE market place, both from an app server perspective and a component perspective continues to thrive with smaller inventive companies who continue to put out viable alternatives to the BEA/IBM behemouths. There will always be a need for lower-cost but very high quality software. I believe that if there were no competitors, even those with much smaller market share than BEA-IBM, then thats where the danger lies. I think its great that BEA has grown to the size that it has become. It is not, however, the only game in town and current status is not a gurantee of future place. While BEA has shown a certain amount of swagger and arrogance (not unwarranted, given their current place in the world), they have yet to succumb to the idiocy of assuming that they don't have to do much to stay where they are. I think they still have the hunger to succeed and still provide a target for others to shoot at. I think industries need the BEAs and the IBMs and that such companies provide value. But there must always be competition to nip at the heels of the leaders so that they can be ready to step in once one of the larger companies stumble.

    Lower cost is very important to the smaller-midsize companies I advise. Very few have the budget (or if budget, no desire) to pay the kind of cash required for BEA. So that the JBosss and Orions and even Sybases, among others, are stronger contenders in smaller companies than those typically served by BEA/IBM. And there are a lot of those companies out there looking for solutions that the really expensive J2EE vendors can't work with due simply to cost. So that market segment will much less frequently buy into the BEA(or IBM)-as-the-only-solution scenario. This is no scientific report, mind you, only what I see, but it is another good reason to believe that there will be (and must be) lower cost but high quality alternatives to the market leaders. It may be that IBM, BEA and maybe Oracle will dominate the high-priced large corporation market segment but there will always be room for at least a good handful of other players.

  99. Well, believe me, I worked with BEA. I posted somewhere else the difficulties we had with 5.1 (and don't intend to repeat here, I think it was in the WebLogic review thread), but I said, 5.1 was ok, but I was very disappointed by 6.0 (and I guess I was not the only one).
    I liked WLS until I saw what was possible with an AppServer (you already know, I'm talking about Borland's).
    Things I particularly dislike about BEA:
    *) There are no tools for deployment etc. (with 5.1 the tools were buggy, ejbc simply didn't compile all classes and didn't say a single word... you had to guess the size of the jar; with 6.0 they dropped all deployment tools)
    *) The console in 5.1 didn't do anything (restart server? All changes gone, how funny! Well, you can change the property files ;-), the 6.0 console is crap because it sometimes destroys the config files, sometimes the GUI doesn't show what is going on in the server (this is of course the Web Browser-approaches fault... I don't like web admin tools)
    *) Both 5.1 and 6.0 crashed quite often... okay, this was during development, but I don't understand why I have to restart the server every 10 minutes to develop something on it (quote "WebLogic no more listening for connections" nice, isn't it? *gg* Same happened if we used the "performance pack for NT" (the native sockets) with requests that were too long. Switching to java sockets worked, but discover this!). 5.1 was stable in production, as I said (although not all too fast). 6.0 was not stable at all.

    hope this makes my point clearer, I said WebLogic isn't the worst AppServer I saw, far from it, but I saw others which show what is possible... and I dislike BEA because they are arrogant and the server is priced too high for what it can do.

    kind regards


    P.S.: This is solely my opinion
  100. I have used both Weblogic 6.0 and IBM WebSphere 3.5.
    As you said that Weblogic 6.0 crashes, i found it very rare.
    I find Weblogic 6.0 is more stable and flexible as compared to IBM Websphere 3.5
    Flexibility i say in terms like i was able to use third party XML parsers very easily with Weblogic as compared to Websphere.
    Even the CMP in weblogic follows ejb2.0 spec.

  101. I have been using and implementing J2EE solutions with iPlanet and WebLogic. Both servers are very stable.
    I thing that what makes an App Server different than another one is around scalability (including distributed, load-balancing features). Both of these servers have great support for clustering multiple Application Servers. I have not looked at other App Server vendors, but I believe that most of them are supporting clustering as well.
    Now somebody brought up CORBA issues. I think that this is very interesting and I do believe that J2EE containers will follow the same path than ORBs: it won't really matter which one is the best (if they implement the specs, who cares). The Open Source community came up with Excellent CORBA ORB implementations. JBoss is on its way to achieve the same thing with J2EE.
    Most of the J2EE vendors are slowly shifting (or should do so) their business around services built on top of J2EE containers. ATG made a smart move by allowing their services to run on multiple platforms. BEA is doing the same with their Web Services offer built in WebLogic 6.1 (but using this will lock you in with BEA).

    I think that the J2EE specs are mature enough to see a real potential in J2EE components resellers.

    The last point is that if you are reselling components based on J2EE, choosing the latests apps servers does not make sense. Take a look at BEA, the company is the only one for now to offer a top notch implementation of EJB2.0. It makes more sense for now to support EJB1.1 and to move toward 2.0 when most vendors will support it. But the main point of BEA (and other vendors) is that they help the specifications to change and improve at a fast pace. We cannot say the same for CORBA with the OMG (see the Design by Committee antipattern) or all the eBxml, UDDI specifications (releasing unrealistic specifications because they have to meet some release dates).

  102. Looking at software history it seems to me that any mature software product area ends up being dominated by not more than three products.

    Maybe people can quote counter examples and maybe this is self-defining, i.e maturity equals domination by a limited number of products.

    There may be room for niche players who meet specific requirements but I believe J2EE-centric app servers will end up being dominated by Weblogic, Websphere and maybe one other.

    Product quality and performance will prove to be relatively unimportant because the big players will (already do?) have the funding/staff to throw at the problem.

    As an example of this, there aren't many people who considered C++ superior to Smalltalk or Eiffel as an OO language but which of them has more code in use today?
  103. Looking at software history it seems to me that any mature software product area ends up being dominated by not more than three products.

    Maybe people can quote counter examples and maybe this is self-defining, i.e maturity equals domination by a limited number of products.

    There may be room for niche players who meet specific requirements but I believe J2EE-centric app servers will end up being dominated by Weblogic, Websphere and maybe one other.

    Product quality and performance will prove to be relatively unimportant because the big players will (already do?) have the funding/staff to throw at the problem.

    As an example of this, there aren't many people who considered C++ superior to Smalltalk or Eiffel as an OO language but which of them has more code in use today?
  104. Geoff -
    You are right - probably for expensive products for companies with appropriate budgets, BEA, IBM, maybe one other, will no doubt dominate the market. I would disagree with your analogy, however, in that its not like a SmallTalk -vs- C++ scenario, its only as simple as J2EE app servers vs J2EE app servers - something much more straight forward. BEA, IBM, and the optional third one will never have 100% of the market. There will always be room for high-quality lower cost app server products. Maybe other companies won't ever be able to compete against BEAIBMOTHER but in trying to do so, they can create terrific products that meet or exceed the quality and technical merits (albeit more slowly achieved) than the big companies.

    The question has been raised: Should the other companies just pack up and go home? The answer to that should be a resounding "No".


  105. Don't think that all "Mature" markets are dominated by only three vendors:
    database market: Oracle, IBM, Mircosoft, Sybase, msSQL; Guess you cannot say Sybase and msSQL are "niche" vendors

    Server OS:
    Sun, IBM (even more than one), Microsoft, HP, Linux (again, though some are smaller players z/OS, HP-Ux, OS/400, Linux, AIX cannot be considered "niche players")

    Netscape, Microsoft, Apache, IBM, BEA, iPlanet (well, Netscape again), hp probably soon;

    there are some other examples like message queuing, transaction monitors, CORBA ORBs (okay, three vendors maybe holds true there), development tools, etc.
    I also think Java and Linux had quite some influence, both showed people and companies that it _is_ possible to compete versus bigger vendors (e.g. Orion) with quality products.

    kind regards,

  106. database market: Oracle, IBM, Mircosoft, Sybase, msSQL;

    > Guess you cannot say Sybase and msSQL are "niche" vendors

    Yes, I assume you mean mySQL, and I would say that Sybase and mySQL are niche players now compared with Oracle, IBM, and MS

    > Sun, IBM (even more than one), Microsoft, HP, Linux
    > (again, though some are smaller players z/OS, HP-Ux,
    > OS/400, Linux, AIX cannot be considered "niche players")

    Server OS: Unix, Microsoft, Linux, ...others...
    Unix OS: Sun Solaris, HP-UX, IBM AIX, ...others...

    > Netscape, Microsoft, Apache, IBM, BEA, iPlanet (well,
    > Netscape again), hp probably soon

    Web Server: Apache, Microsoft IIS, ...others... (who really pays for just a web server any more? The others are app servers)

    I think all of these areas show the basic pattern of mature market spaces. The reason that the server OS market is slightly more fractured has to do with the history of Unix vendors fighting it out to be the remaining finalists in that market, letting Microsoft and Linux grow as alternatives. Now you can more or less break up server OS markets as I have, Unix vs. MS and Linux, then Unix vendors vs. one another, which is really more about hardware than OS at this point.

  107. Jason:

    Yes, I meant mySQL of course ;-) just a typo
    Regarding the WebServers: I disagree. BEA WebLogic Express is far from an appserver. For me "AppServer" means anything which can host EJBs and related technologies, or something similar. iPlanet is often used as WebServer, as well as IBM http server (which is a slightly modified Apache).

    And still I think Sybase and mySQL are no "niche" databases. Interbase is probably "niche", but mySQL? Guess 90% of database powered sites use mySQL. Though probably not the really big ones. But hey, Sybase?

    Same holds true for unix, as AIX is well different from HP-Ux and Solaris. Though it makes no _real_ difference of course, but I could also say this for WinNT/Unix. No real difference, it hosts my applications ;-).

    Okay, but I guess we have different views here ;-)

    kind regards

  108. Well I guess we're getting off topic and one can define niche, dominant how one likes but at the other extreme you could say that a software vendor that only supported Oracle and SQLServer were not shutting themselves off from too big a slice of the market.
  109. <quote>
    Well I guess we're getting off topic and one can define niche, dominant how one likes but at the other extreme you could say that a software vendor that only supported Oracle and SQLServer were not shutting themselves off from too big a slice of the market.

    Errr, wrong.

    If you chose to support only those platforms then you just ruled out most of Wall Street and the Square Mile in London.

    Most banks run on Sybase. Why? Because it is very quick at OLTP and it's pessimistic locking model fits very well with the kind of database access banks need.

    Remember, the number of players in the market is not as important as how much money they have.

    And don't believe the hype from Oracle about their assault on the financial sector. The cost of converting to Sybase is huge for these companies, plus Oracle offers them very little in terms of advantages in their space, and the change from pessimistic to optimistic locking would kill most of their (somewhat badly designed) systems.

    Just my 2c worth, based on my time working in just this sector.


  110. Hi,
      Where does one start?
      I have been evaluating software for an important university, and I have my own criteria for the software.

      BEA had the decency to reply to my initial queries and quoted quite a high price, Bluestone chased me for some feedback that was not entirely complimentary, the product is OK, but I was looking for a student learning tool that was usable.
      I emailed JRUN who never bothered replying, shame as I was quite impressed with the tool (Allaire, I think). JBoss was free and looked good, Orionserver is excellent, but I did not follow this trail, etc. etc.
      Apart from the cost and feedback from sites, there is the usability, and I still I like the j2skd1.2.1, i.e. the java developer version for j2ee. It's the business for most apps.
      Also, as a newcomer to IDE's like Together and Forte, I was very impressed with the same. Both again good products, and at a very reaonable price(to the Uni).
      I believe that mny of the vendors do not still take into account the good work they could be doing with Universities as far as offering a decent package price for their software, and thus the follow on effects when those students recommend the same to the many ignorant people out in the market place (generally IT bosses), I met many when working for CSC (computer Sciences Corparation) who did not hava a clue what they were talking about! C'est la vie!

      Back to talking about j2ee software, I asked for feedback in comparing BEA Weblogic and JRun on the java discussion forums, and received some interesting feedback. The most interesting referred to the suggestions for trying other vendors packages (albeit never Microsoft)!!!!
      I might be wrong, but I would suggest that there is a great unknown void as to the best solution and my small efforts in educating businesses to share some of their knowledge for free to the Uni's will become a distinct advantage when the ignorant bosses spend their/other peoples money (rather than at the bar) - I am again referring to a Consultancy company again rather than some where in AcademiaLand.
      Anyone can email me at kevanwilding at aol dot com or if you have any surprisingly good deals at kwilding at essex dot ac dot uk

      I am particularly looking for sofware companies to make clear to the customer what the software can do in reality with lots of good simple tutorials, but also more importantly some real life applications that will work in all environments (or most), and aimed at the newbies that require extensive guidance in learning a new technology, a new programming language and also what can be done with it.
      As an aside, but as important, if not more, is the accessibility options for people with learning disabilities, or just plain deaf or blind. I know that some work has been done in this arena, but I am not impressed with the way that is eiher forgotten in some products, or just added later.
      I quote Together as a brilliant tool with no accessibility options, but I am sure there are many others.
      Apologies for quoting CSC as the PITS in consultancy!

      Best regards,
                  Kevan Wilding
  111. Well it really depends. For easy development I consider Borland AppServer the best tool, together with JBuilder as IDE (I however also think that BAS is one of the best runtimes available). The tradeoff you will face is the very high price, which may be too much for a university.
    You'll get a free development license of BAS with JBuilder Enterprise.
    I liked Together a lot, however, I hate their new licensing scheme (well, in fact I hate flexlm) and the new Together 5 seems to have some bugs, especially with ER diagrams, so I'm not using it anymore other than for UML.
    You may want to try the Borland products, guess you'll be impressed by the ease of use.
    For a low price I'd however recommend J2EE RI together with Forte. I _would_ recommend jBoss, however, I think using Forte with the J2EE RI plugin is easier, there is AFAIK no plugin for jBoss (although you just have to drop the files into a special directory). Especially because I cannot see any advantage in e.g. Orion or JRun or whatever compared to jBoss/J2EE RI, as long as you are developing with it.

    kind regards

  112. There was once an old king whose country adjoined that of a neighboring king with an even larger and more powerful kingdom than his own. Now the first king had many legitimate children, some weaker, some stronger to whom he extended his paternal blessing. He also had a natural child. Although the natural child contained the DNA of the father, he did not receive the paternal benediction. It was the first king's sincerest hope that his sanctioned children would grow strong, not only to defend his kingdom but to conquer bits of the neighborhing king's land. However, these children fought among themselves for control of the various duchies within the father's kingdom. The neighboring king took advantage of this discord to start winning over some of the first king's subjects. Meanwhile, the natural child flourished and found favor with many of the citizens of the kingdom, so that he too began to carve out a duchy of his own and compete with his siblings.

    Don't underestimate JBoss. Don't know where they are in the certif. process, but their downloads are killing it on Sourceforge. While the high-end J2EE vendors fight it out among themselves, .NET is coming in and flanking them on the low end.
  113. Its not correct to leave just a couple of vendors dominate the j2EE server scene.
    Infact the open source org's ahould be supporeted to cone out with servers which will server for low end projects.

    The enterprise really are not willing to invest heavily on app servers..
    rest there are not much projects whichh really need high end J2EE servers