Java开发网 - Weblogic or Webshpere

Java开发网

您没有登录

» Java开发网 » Java IDE

打印话题 寄给朋友 订阅主题

作者

Weblogic or Webshpere

terrence3321

Jute User

发贴: 40
积分: 50

于 2003-02-28 04:28

Recently I had to migrate a web+ejb2 application from WebLogic 7 (WLS) to WebSphere 5 (WAS). Through this process, I learned many things about WAS5. I am writing this document to share my experiences with others who may find themselves in the same situation as I did and with those deciding whether WAS5 is for them.

I have done web+ejb development using WLS, WAS and Tomcat on prior projects. My experiences with WAS 4 on these projects were typically less than positive to say the least. Much time was always spent applying fixes before I could do any meaningful work. That experience and the lack of EJB2.0 had me recommending to my clients that they stay away from WAS, especially if they planned to use entity EJBs.

With WAS5 my experience has been much better. This rev seems to be a more mature version 1 release than its predecessors are. In WAS3.5 and WAS4 the EJB support relative to the competition was, IMHO, a sad story. WAS5 has a good story and despite some weaknesses, the EJB container is finally competitive with other leading products.

Documentation:

WAS5 documentation is still very poor when compared to WLS7. The Info Center lacks many important details and does not contain sufficient examples. Either examples that come with the server are too complicated or they do not have the necessary detail. Redbooks from IBM written for WAS5 specifics are a must read, as they add the details missing from the Info Center. For many common issues you have to search the support site and the search cannot filter well documents for a specific version. The main complaint here is that information is hard to find and requires a lot of detective work to find it. IBM has a WLS to WAS5 migration Redbook that does not contain much information other than the obvious things. Details about migrating EJBs, the place where the two products are a bit different (read WAS has a bit less features than WLS), are conspicuously missing. I think that they still have to work on this one, maybe merge Info Center, some support articles with the Redbooks (while removing the boilerplate and the countless pages of J2EE generalities).

Installation:

All the products in this space are big but WAS5 is really big. It comes with a nearly 160Mb installer and almost 100Mb of memory-footprint. This is before installing any applications! In the world of multi-gbyte servers this might not seem significant but on my 512Mb laptop it certainly is. There is a must-read article (Optimizing Multi-Project Builds Using Dependent Project JARs is WSAD) that explains how to configure the JVM for WAS and WSAD to maximize performance when you develop.

The installer was quick and the server ran out of the box. All in all the installation process is much improved over WAS4 were one had to apply patches right after the installer.

The startServer script by default launches the server in the background and sends output in log files. I wanted to start and stop WAS in a Command window so that I would not have to look in various log files to check on the status of my server. I discovered an argument, -script, to the startServer script that solved my problem. It generated a script that runs the server in the foreground.
Administration:

Finally, WAS5 looks very professional with its web-based console, a step ahead from the multi-megabyte installed Java console. Looks are good, they use Struts (and I like that as I am a fan). I still think that WLS's console is easier to figure out but the power we expect from the console is there. I could not find any extensibility API for the console the way WLS has but I do not see this as a major drawback.

I found two interesting concepts that IBM exploited very well and that set it apart from WLS. First is the ability to configure things at the cell (cluster wide), node (machine wise) and server (JVM) level. For example I can configure a connection pool to be cell wide or available only on a particular node or server. The other is the definition of path variables (much a-la WSAD class path and path variables. This really makes the moving apps from development to testing to production much easier and allows us to check into CVS the server configuration files. I hope they exploit the last one to define generic properties so we could use ANT-like values property substitution.

In WAS5 IBM uses JMX - a bit late compared to JBoss or WLS but this is a big step in the right direction. They even document the MBeans that control the server and its internals so you can write your own monitoring tools.

However, the most impressive feature in the administration section is the wsadmin command line tool that integrates BSF (Bean Scripting Framework) with the JMX management. This gives us a scripting interface to the server. This is a great feature and I bet you will see this in the next version of WLS and JBoss. One of the useful ways to make use of this feature is to write a script that will configure a cell, node or server for a given application, creating data sources, connection pools, JMS destinations and such, making the life of lazy developers and administrators much better. Now we have a better way, other than documents, to capture server configuration and administration tasks.

Web Container:

IBM has done a lot of work here and the WebSphere suite adds an Apache 1.3.26 based web server and an edge server. Support for a generic Apache and IIS is there, as is the support for load balancing and clustering/failover (features available only in the Network Deployment version of the product).

From a developer point of view, the Servlet 2.3 and JSP 1.2 are there and they work. Fortunately, the specifications do not give vendors a lot of liberty, as is the case with the EJB, so I could find no difference from WLS or Tomcat with my code.

I could not find out how to have the server’s JSP compiler generate JSP Java source code and make them available for debugging. However, the debugger works off the JSP file – neat! I am sure there is an explanation in some Redbook or technical note - but then why do I have to read so much to achieve such simple goals?

EJB Container:

The EJB container is EJB2.0 compliant without a lot of interesting features but with some other unexpected ones.

The server requires an EJB compiler that generates an impressive number of classes for each EJB you have. This process is a bit slow for my taste and I have to say I like the proxy/aspect/interceptor approach of JBoss better. I cannot understand the need for the stub-skeleton in EJB (RMI, IIOP, JRMP or any other protocol) once reflection and dynamic proxies were in place. Nevertheless, in the end it is the same as WLS.

Strangely, there is no PK generation mechanism. I had to look in a book and quickly implement a session bean that generates primary keys and changing code in ejbCreate() of a lot of entity beans. Couple of hours of work in the end but I expected more from a server coming from IBM. I expect an app server to at least support Oracle sequences, auto-incremented columns and a generic mechanism where there is a table with sequences names and values. WLS is ahead in this area.

In addition, there is no support for field groups. You cannot have a finder that only loads the ID and NAME from a customer in the entities, and the rest of the fields on demand. This is a small performance optimization, not part of the spec, but it may come in handy when the entities have many fields. WLS is ahead in this area.

The strangest is the mapping of entity fields to table columns. The EJB-Database mappings are for a specific database. This sucks. If I develop an application with EJB 2.0 entities I expect to be able to move it to a different database in minutes – on WLS and JBoss this is possible. With WAS this is much more difficult. For example, I wanted my application to work with both the embedded Cloudscape DB (they now call it DB2j) and with Oracle. I was forced to define the mapping twice.

Another interesting thing is how they classify mappings:

- top-down (names of tables and columns are derived from your EJB name and field names - this must give nightmares to DBAs),
- bottom-up (when the names of the fields in the EJB are derived from the tables and columns as if any developer likes the names defined by the database designer), and
- meet-in-the-middle which is what everybody else is doing. Unfortunately, this mapping can only be edited with WSAD or a plain text editor dealing with four XML/XMI files.

MySQL was conspicuously missing from the list of supported SQL servers for CMP purposes. It was really upsetting to see this given that version 4 supports transactions.

It is nice that WAS supports EJB entity inheritance and custom mappings from the JDBC result set row to the entity bean. This way you can, for example, take a number column and map it to a Money field. I read in the docs that dynamic EJB-QL is available in some Enterprise version as is limiting the number of rows from a finder or query. I think it is pathetic that these features are not part of the EJB 2.0 specification (Did the people that wrote the EJB spec ever implement an application?)

The EJB container supports different locking modes for the entity beans: pessimistic (one can have findByPKForUpdate() as a finder like findByPK() but with the added functionality that locks the row in the database on select) and optimistic where the locking happens at update time.

It is quite difficult to plug in a different database driver than the ones supported. WLS wins this comparision by supporting any JDBC compliant driver.

JMS Container:

I was able to create an MDB after reading an article in WAS developer website. The administration concepts in this area are a bit complex and confusing - WLS has an edge here.

In this version WAS has a Java only JMS server but it is not suitable for production. IBM suggests you use WebSphereMQ (former MQSeries). For development purposes the bundled JMS does the trick.

Security:

I was surprised to find that the development version of WAS does not have a database user registry or realm. However, they have an interface for pluggable realms and a good example implementing a file based realm, from which you can derive your own implementation. Do we all have to use our OS or LDAP? In WLS setting up a database realm is quite simple.

The SSL configuration is a bit more flexible than WLS. A server can have as many SSL configurations (keys+certificate+trusted certificates) as needed which is good when hosting multiple applications.

JAAS works in a standard manner – WLS requires the use of a proprietary callback for the server URL making the code non-portable out of the box.

Other Features:

Web Services support is there but I did not make use of them. From what I have seen one can deploy a simple Java class or an EJB as a web service. The process to get this done is quite involved if you follow the tutorials and Redbooks. The SOAP implementation is based on Apache SOAP rather than the newer, more advanced AXIS implementation.

A nice feature is the ability to create an Application Client EAR. The launcher simplifies the application startup and makes JNDI usage simple. This is the right way to package clients for distribution!

When I tried to start a simple EJB Java client from the command line (our JUnit tests), I was surprised to find the necessary info (jars in class path and command line arguments, initial context setup) only in the WAS5 Security Redbook - strange but at least it was somewhere. You have to specify many –D JVM options and have three properties files available. All this is more complicated than in WLS. All you need in WLS is the weblogic.jar in classpath and to set up two parameters in the InitialContext(). This is simpler but has the drawback that you have to distribute the huge weblogic.jar to installed clients.

Development Features:

Applications can be deployed in an unpacked EAR where each module is a directory containing the content of the jar files. Auto-redeploy can be enabled and works well for web applications but not so well for EJB. I found that in some cases the when the EJBs are redeployed (even under
WSAD) there are errors that disable the EJBs and the only way to get them back is to restart the whole server.

Tools:

The biggest disappointment here was that in order to deploy an EJB application that uses meet-in-the-middle mapping you MUST use WSAD or edit XML files yourself. AAT, Application Assembly Tool, knows only about top-down and bottom-up mappings. Do they think this a compelling enough reason to buy a few thousand dollar tool?

Many developers will use WSAD but others will use lower cost tools. JEdit + ANT or Eclipse + ANT will work as well as they work for WLS. I could not find more details for the level of support for WAS5 in XDoclet but that should be available soon I hope. The mid cost IDEA/IntelliJ should work as well as it does for WLS.

At the high end we have JBuilder 7/8 (J Black Eye

and WebSphere Studio Application Developer 5 (WSAD). Both are good. WSAD was impressive in terms of features (this should be the subject for another review). I find that the EJB tools are much better and intuitive in JBuilder (maybe IBM developers will check JB out and make their product better in the EJB area). Especially disappointing is the lack of support for create() methods, management of the EJB methods signature and poor organization and readability of transaction attributes and references.

Conclusions:

For me J2EE 1.3 adherence matters and from what I could find WAS was there. Despite the fact that their EJB container is not on parity with WLS in terms of ease of use and features the overall feeling of the product is good.

If your boss told you that tomorrow you have to use WAS do not be scared. It will be a rough ride through the docs and small issues but once you figure them out it can be quite productive. I would suggest using WSAD and having technical support contract and, if possible, access to a WAS guru.

Given a choice between WAS and WLS I would still choose WLS. The main reasons are better documentation, easier to understand, somewhat easier to administer, more mindshare, better newsgroups (less noise) and the fact they have a bit more feature-laden EJB 2.0 container that has been around for a couple of versions.

Reading past reviews to big-vendor application servers I have seen a lot of comments that praise open source products and asking why would someone buy vendor X application server for $$$ when they can use JBoss for $0$. My answer to that is that for many companies that hire consultants to run a project, the application server license is a small fraction of the overall cost - a small impact means little interest, more impact of big-vendor marketing which, in the end, matters.

话题树型展开

人气	标题	作者	字数	发贴时间
4098	Weblogic or Webshpere	terrence3321	15011	2003-02-28 04:28
3281	Re:Weblogic or Webshpere	davidself	15	2003-02-28 06:59

已读帖子

新的帖子

被删除的帖子