A
J2EE Server Comparison

This chapter compares WebSphere Advanced Edition 3.5.3 to Oracle9iAS OC4J in the following areas:

• Installation and Configuration

• Code Portability

• Database Connections

• Security

• Performance and Scalability

Installation and Configuration

• Setting up WebSphere is complex and is different on different platforms. The most stable version of WebSphere is v3.5, but it requires service pack 3 or 4 in order to be J2EE 1.2 compliant. If there are problems during the installation of the service pack you cannot un-install or re-apply the service pack; you must re-install WebSphere.

  Oracle9iAS OC4J takes only a few minutes to install and start.

• WebSphere requires a database repository for installation, and to run applications. WebSphere stores server and application configuration data in the database, even for a single instance of WebSphere. Because of this, starting an application takes an unusually long time, even in a development environment. DB2 must be installed before installing WebSphere 3.5.x.

  OC4J uses standard, easy-to-configure .xml files for server configuration and J2EE applications deployment. An administration repository (Oracle9iAS infrastructure) is not required unless a cluster with more than one Oracle9iAS instance is required.

Code Portability

• WebSphere requires developers to use proprietary packages for standard J2EE features. To use servlet chaining or filtering, developers must use WebSphere-specific packages. These are not WebSphere-specific features but are part of the J2EE servlet 2.3 API specifications. Hence, WebSphere 4.0 does not support the Servlet 2.3 API requirements.

  OC4J is fully complaint with the latest Servlet 2.3 API

• WebSphere v3.5.x CMP entitity beans are not portable. The WebSphere EJB container requires every CMP entity bean to define an interface named <ejbname>FinderHelper. This is not defined in the J2EE standard and is not portable.

• WebSphere-specific access beans are not portable. WebSphere strongly influences developers to use access beans. These are client side beans to access EJBs and are not portable. The VisualAge tool generates access beans by default.

  OC4J is fully complaint with EJB 1.1 and also supports advanced features of EJB 2.0 (WebSphere 4.0 does not support the EJB 2.0 spcification).

Table A-1 shows the level of J2EE support provided by versions of WebSphere and OC4J.

Table A-1 J2EE component specification version support

Technology	WebSphere 3.5.3	WebSphere 4.0	Oracle9iAS OC4J
JDK	1.2.2	1.2.2 and 1.3	1.2.2 and 1.3
Servlets	2.1+	2.2	2.2 and 2.3
JSPs	1.0	1.1	1.1
EJBs	1.0+	1.1	1.1 and 2.0
JDBC	2.0	2.0	2.0
JNDI	1.2	1.2	1.2.1
JTA	1.0	1.0	1.01.
JMS	1.0	1.0	1.0.1

Database Connections

• WebSphere consumes more memory for each database connection it opens.Prepared SQL statements are cached across the pool of connections, by J2EE server, for faster execution. WebSphere connection pooling fails if you try to create more than one prepared SQL statement simultaneously per connection.

  OC4J supports more than one prepared SQL statement simultaneously. This significantly improves database access performance in OC4J as compared to WebSphere.

Security

• Enabling security on WebSphere degrades performance significantly for EJBs. Application response times degrade by a factor of two. For each EJB interaction triggered by a HTTP transaction, WebSphere generates a large log output when security is enabled. Also, WebSphere is not 100% complaint with J2EE security APIs. For example, calls such as is CallerInRole does not work (a NotImplemented exception is thrown).

  OC4J is fully compliant with J2EE 1.2 security APIs.

Performance and Scalability

• WebSphere uses RMI-IIOP to communicate between components. This is particularly troublesome in the Enterprise Edition in which the Component Broker performs the dual role of EJB container and Object Request Broker (ORB) server. WebSphere is known to have performance problems with its RMI-IIOP implementation due to its use of the CORBA cosNaming service for object lookup.

  OC4J uses a very efficient and optimized RMI (ORMI).

• Co-located servlets, JSPs, and EJBs have very short code paths in OC4J compared to WebSphere.

• Container-managed persistence with associations causes performance problems in WebSphere. WebSphere support for CMP association does not cache the InitialContext nor the EJBhome objects. As a framework, it uses lookups extensively through the homes, with each home lookup equal in performance cost to executing 4 DB "SELECTs". It is recommended that you build a caching "HomeFactory" for application use as well as make changes to the association framework so that it also uses the caching "HomeFactory". These functionalities should be addressed by the EJB server itself (as they are by OC4J).

• EJB-to-EJB communication is very fast and efficient in OC4J as compared to WebSphere. OC4J uses local non-RMI calls within a given JVM.

• WebSphere requires tuning of too many parameters to realize any performance improvements. The following parameters must be tuned for performance:
  • JVM

  • Transport queues between HTTP listener plug-in- Open Sevlet Engine(OSE) and Servlet Container.

  • Servlet auto reload (this feature is part of hot deployment and causes performnce problems since the Administration Server has to update configuration information in the database).

  • Transport queues between sevlet container and EJB container.

  • ORB ( for enterprise edition).

  OC4J requires very minimal tuning as compared to WebSphere. The latest release of WebSphere, version 4.0, replaces support for multiple transport protocols with a single HTTP-IIOP protocol to commnicate between the HTTP server and application server.

• WebSphere consumes more resources (CPU and memory) than OC4J. This not only true for starting the application server, it is also true for each request.

• WebSphere clustering performance degrades for more than 3 to 4 nodes in a cluster.

• The EJB container in WebSphere Enterprise Edition is based on that in the WebSphere Advance Edition.