WebSpehe Vs Weblogic


XML & Web services: WebSpehe Vs Weblogic

  1. WebSpehe Vs Weblogic (2 messages)


    I am a newbie in web services.I have to work on a project that invovles integrating .NET and J2EE using web services. The client will be a C# client while the server side logic will be written with EJB's. The EJB's will then be exposed to the client side as web services. I am confused as to which of the two - IBM WebSphere or BEA WebLogic - would be a better choice as the app server for integrating with .NET. I noticed that WebSphere has good documentation on the developerworks website on integrating with .NET clients. Does BEA have such documentation and level of support

    Could some one please help me in this regard



    Threaded Messages (2)

  2. WebSpehe Vs Weblogic[ Go to top ]

    If they are your only two choices, save yourself some pain and go with Weblogic... if you really need to use EJB. Steer clear of Websphere altogether. Even Websphere 5 (previous versions were horrible) is a pain to use, and really clunky to set up and administer.

    I and our production support teams have spent considerable time with both, and there is a clear consensus which is less trouble to support in production and which is actually usable for development.

    Specifically, with Weblogic, you have a simple ant task that you run against your EJB-JAR to expose your specified EJBs as JAX-RPC compliant Soap Services. It literally takes you 5 mins to write it into your ant script.

    The question does need asking: Why do you want to do the client in C#? There seems to be a lot of "word on the street" that this is the best mix of technologies, but it really isnt true in practice. You can do a very professional Swing client or, equally, an Eclipse RCP client with none of the integration hassles that you will have doing a mix. Not to mention, using Java Webstart will give you a zero-admin deployment mechanism (zero installation)

    The other question is do you need EJB? Do you need XA transactions?
    EJB gives you a simple means of having a remotable component with declarative (XA or non-XA) transactions and security, with the simplicity of a single-threaded environment.

    However, if your only remoting is going to be SOAP, you can achieve a similar result using something like glue for your SOAP engine (they have a free version - it has an embedded http engine for SOAP endpoints) and spring for doing declaritive transactions, and hibernate for your database persistance... all for a lot less development effort and a lot less money.
    However, if you have to do XA transactions (more than 1 database or mix of database and messaging) then get yourself an appserver - preferably not Websphere...

  3. WebSpehe Vs Weblogic[ Go to top ]

    I agree that Weblogic is all around a lot easier to configure and use.

    That said, webservice support should not be your deciding factor on a J2EE container. They are huge investments and on many of my projects overkill for the work that actually needs to be done.

    Have you considered just using a cluster of Tomcat servers. Or similiar?

    You only need a web server to support webservices and there are plenty of tools available to create a webservice from a POJO.

    Something like Hibernate would do your persistance.

    Do not go down the full J2EE container route unless you absoultly cannot live without some feature because it adds an order of magnitude to your project at all stages of your process.

    I just got back from a java symposium and some of the best minds in the business are rethinking the complexity of J2EE (EJB's, etc.). EJB 3.0 will probably look a lot more like Hibernate. This is comming from people on Sun's board.

    I love Weblogic but it is too large a tool for many common projects.