Performance and scalability: iPlanet&Websphere&Weblogic

  1. iPlanet&Websphere&Weblogic (3 messages)

    Do anyone have any comparison between those application server? Any comment on which one perform the best? If I want to integrate IBM mainframe(CICS), does it imply I better choose websphere?


    Threaded Messages (3)

  2. iPlanet&Websphere&Weblogic[ Go to top ]

    Yeah I'd go with Webshpere.
    Although I don't have experience with iPlanet, Websphere was a better choice if for nothing more than the support with the OS/390 environment. We implemented Websphere to an IMS DB on OS/390. IBM has built a OS/390 connector archecture called Enterprise Access Builder (EAB) which is included with their Enterprise Visualage for Java product. Using VAJ and EAB we built a messaging service to the OS/390 using COBOL copylibs. I am almost positive you can do the same thing with CICS that we did with IMS DC.

    I would say for UI and the Business Object layer Weblogic is a better choice. I liked Weblogics administrative consoles better. Websphere is very fussy about servlet paths especially with applicatons that do not run in their default JVM on the server. I thought weblogic spelled this out a lot better. However, for the connectivity to the mainframe IBM beat them and thus got our business.
  3. Websphere vs Weblogic[ Go to top ]

    are you really think that IBM's connectivity to the mainframe makes WebSphere quite unique among others?
    There is no gap in the market, especially in enterprise level niche. There are lots of ISVs who offer integration and bridges to mainframes. So you can chose the best app. server according to it's main proposal - managing j2EE applications, and purchase a separate product for mainframe integration.

    I worked with WebSphere for more than half a year, and my experience outlined it's two REALLY significant drawbacks:

    1) As it was said, WebSphere is far from being compliant to J2EE standards ( 3.0 has only JDK 1.1.7 and this version of JDK is specific to app. server) and this really makes development very far from being convenient. Before I started with app. servers I read Servlet, J2EE, EJB and other Sun specifications. So it took a long time to understand that there were nothing common with those specifications I had read (Docs lacked for it and I could made all clear only after some time, searching web site).
    As for future releases, version 4.0 (available early 2001 as they said) expects support for JavaMail (at long last!), EJB 1.1 (3.5 does only 1.0), JDK 1.3, JMS (3.5 has only MQSeries native support), JNDI over LDAP (3.5 does only JNDI 1.1 for EJB lookup and COSNaming), JSP 1.1(again, 3.5 does only JSP 1.0 and 0.91 API levels), Servlet 2.2, some security enhancements(3.5 does end-to-end EJB security, partial Java security APIs). - Not impress much: they are far behind competitors, some of which are already J2EE certified. As for BEA, as you know, they will release 6.0 version with partial EJB 2.0 support by the end of this month..

    2) Deploying beans to WebSphere was a real nightmare. First there no automatic deployment/redeployment, so I had to manually create JAR's using jetace utility (WAS does not support XML deployment descriptors and has it's own format), next I had to manually place this JAR in WAS EJB's directory, deploy it with console, and only after that use my beans in applications.
    Furthermore I had to do it each time while debugging EJBs. Successful deployment does not mean that your beans could start, even if pinging them in console states that they are running.. We didn't use VAJ, because we had AE version, which was shipped with VAJ Standard Edition. But only Enterprise Edition supports J2EE features.
    But I couldn't evaluate it because IBM does not allow to download trial version.
    So I really can't understand the reason that IMB does not allows to evaluate it's J2EE products - WebSphere(current 'trial' version 3.5 is available only to execute examples supplied with it, you can't deploy and test yours) and VAJ EE, while most J2EE ISV's do this.
    I think the reason is IBM's marketing strategy - they suppose that being the biggest corporation in the market eliminates the needs to ensure independent companies and developers in theirs products quality..
    IBM's position in J2EE market could be maintained only by it's business partner's demands.
    This does not mean that IBM's J2EE market will not grow in future, quite the contrary, according to various forecasts IBM will take the biggest part (with BEA) in the market.. (As for me, today I'm really doubt about it)

    As for now, I wash my hands of it and will evaluate BEA WebLogic(already 6.0?!), Sybase's EAS, Gemstone/J and IONA's iPortal. Except Gemstone all of these are J2EE compliant and certified (After WAS experience I realized all it's benefits) - this means no headache in development and future maintenance process and also compatibility with any J2EE IDE and a tool.
  4. Websphere vs Weblogic[ Go to top ]

    About your 2 comments...

    1. Agreed, I also had quite a few problems in Websphere 3.0 using the IBM JDK 1.1.7b. Deploying from VAJ to Websphere sometimes gave me "NoClassDef" errors which were only solved by a recompile outside of VAJ in the correct Websphere JDK. I am told this is solved in WAS 3.5 since it uses the Sun JDK 1.2.

    2. I don't have as much experience with EJB deployment since the issue of remote messaging and transaction management has not appeared until we have developed enough applications to require it. With that said, it remains our greatest obstactle now. Especially since the growth of Java applications is fast. Applications are beginning to use their own implementations of messaging (XML via a HTTP Servlet Message) which is asynchronous and has no rollback mechanisms. It scares me to hear all your problems with your bean deployment in WAS.