A
Additional Feature Comparisons

This appendix provides additional comparative information between WebLogic Server 7.0 and Oracle Application Server 10g. This information consists of:

• Java Messaging Service (JMS)

• Java Object Cache

• Dynamic Monitoring System (DMS)

• Active Components for J2EE (AC4J)

• Oracle Application Server TopLink (OracleAS TopLink)

Java Messaging Service (JMS)

Oracle Application Server 10g and WebLogic Server 7.0 both support JMS 1.0.2. Table F-2 highlights some of the key JMS features supported by both application servers.

Table F-2 JMS Feature Comparison Summary 

Feature	Oracle Application Server 10g	WebLogic Server 7.0
Pluggable JMS Providers	Yes	Yes
Message Retention and Query Ability	Yes	Yes
Persistence of JMS Messages	Yes	Yes
Failover of Persisted JMS Messages	Yes	No
Message Payloads: Structured Datatypes, Unstructured Datatypes, Relational Data, Text, XML, Objects, Multimedia Data	Yes	Yes
Message Transports: SOAP, Net8	Yes	Yes
Secure Access	Yes	Yes
Abstraction of Business Logic, Rules, and Routing into Easily Maintainable Tables	Yes	No
Guaranteed Delivery	Yes	No
Ability to Cluster in a High Availability Configuration	Yes	No
Interfacing with Java and Non Java Clients	Yes	No

Oracle Application Server provides support for JMS in the following manner:

• Fast, Lightweight, Compliant - Oracle Application Server provides two out-of-the-box JMS implementations.

  The first is OracleJMS, which uses the Oracle databases integrated Advanced Queuing (AQ) to offer secure, transactional, recoverable, and guaranteed delivery of messages. Oracle Application Server also offers a fast and lightweight, in-memory JMS that can be used to pass messages between applications in the middle tier. In contrast, WebLogic provides a simple JMS implementation.

• Pluggable JMS Providers - Oracle Application Server J2EE applications can access queues and topics using the JMS API. They can use an Oracle Application Server specific JNDI namespace to look up JMS ConnectionFactories and Destinations.

  Oracle Application Server defines a ResourceProvider interface for plugging in message providers and provides the implementation classes for Oracle's Advanced Queuing and for third-party messaging systems such as MQSeries, SonicMQ and SwiftMQ. The ResourceProvider interface allows switching between message providers transparently to the JMS client. JMS clients can mix messages from multiple messaging systems in the same application, and switch between them by merely changing the JNDI mappings, and without any changes in the source code.

  WebLogic has lesser support for plugging-in other JMS providers. Its approach to supporting IBM MQ Series is complicated. Developers need to use BEA WebLogic MQ Series JMS classes, a separate library of classes, to plug in MQ Series. Oracle Application Server, on the other hand, makes it extremely easy to plug in, almost as simple as a DataSource.

OracleJMS (OJMS)

OJMS is the Java front-end for the Oracle database integrated Advanced Queuing (AQ), which offers secure, transactional, recoverable, guaranteed delivery of messages.

Advanced Queuing provides a number of important facilities. OJMS leverages the Oracle database robustness, query-ability and DML operations, scalability and high availability, and support for all data types in message payload, including relational data, text, XML, and multimedia.

The following general features are discussed:

• Message Retention and Query Ability - OJMS integrates a messaging system with the Oracle Database leveraging the databases robustness, and providing guaranteed message retention and auditing/tracking while eliminating the need for 2-PC operations between the messaging system and the database. Further, since the queues are stored in the Oracle Databases, they can be queried using standard SQL.

• Message Payloads - OJMS can support a variety of structured and unstructured datatypes as message payloads including relational data, text, XML, objects, and multimedia data.

• Message Transports - OJMS also provides support for reliable once-only, in-order delivery of messages over a variety of transports including SOAP, Net8, and others. It can also use other messaging providers such as MQ-Series for transport.

• Secure Access - Finally, OJMS provides stringent access control on individual queues and messages using the databases ACL mechanisms.

WebLogic Server does not have the following set of capabilities that Oracle Messaging (JMS) provides:

• Abstraction of Business Logic, Rules, and Routing into Easily Maintainable Tables - OJMS has extensive rules functionality. Rules can be used for efficient routing of messages. You can specify rules as SQL expressions when defining your subscriptions. Rules engine performs efficient rules evaluation. These SQL expressions can contain any other PL/SQL, C or Java function. With the Oracle9i Database (Release 2), you can also organize your rules in rule-sets and use rules functionality independent of message queuing.

• Guaranteed Delivery - OJMS provides guaranteed once and only once delivery. This is a feature unique to OJMS. You can monitor messages in the queues using SQL views. You can write a single SQL statement to find out exact location of your message.

• Ability to Cluster in a Highly Available Configuration - With Oracle Advanced Queuing, you get benefits of the entire Oracle stack including persistence, high availability and scalability with Real Application Clusters (RAC).

  On the other hand, BEA WebLogic JMS clustering is not as robust. One of the key considerations in the choice of JMS is reliability. WebLogic Server does not have failover of persisted messages pertaining to a server failure. Further, it provides failover only for JMS destinations. However, these JMS destinations are not replicated. For example, you can deploy multiple persistent queues with the same JNDI name across all nodes of a cluster. A client will hit just one until that node fails, in which the cluster will transparently failover the client to the next available node/queue.

  However, what's stored in the first queue remains in the first queue since it is persistent until someone manually brings that node up again. Or, you need to find some mechanism for retrieving the messages yourself. Oracle Application Server and Oracle AQ, on the other hand, can leverage the high availability capabilities of Oracle9i RAC to avoid this problem.

• Interfacing with Java and Non Java Clients - The WebLogic Server implementation of JMS does not allow sending messages to non Java clients. Oracle Application Server JMS, through Oracle AQ, has four APIs - PL/SQL, Java (JMS), C, and XML. This enables a message to be enqueued from any language and dequeued from any other language, thereby providing the flexibility to integrate with various heterogeneous systems including legacy systems.

Java Object Cache

The Java Object Cache is designed to improve access performance for shared Java objects and to reduce SQL-to-Java overhead (database access overhead). The Java Object Cache is distributed and can be accessed in-process, across process boundaries on a single machine, and across processor/machine boundaries.

To improve performance, the creation of Java objects is distributed to avoid bottlenecks. The cache is configurable, allowing objects to be grouped, pooled, pinned, and paged as necessary. Finally, the Java Object Cache is clusterable with updates that can be synchronized across clusters.

The goal of the HTTP-level (for servlets), and EJB clusters is to provide a load balanced and fault tolerant system. The Java Object Cache focuses on providing better performance by distributing pre-computed objects across the Oracle Application Server instances so that expensive computation is done only once.

The Java Object Cache is an in-process cache of Java objects that can be used on any Java platform and by any Java application. It allows applications to share objects across requests, across users, and coordinates the life cycle of the objects across processes. The Java Object Cache enables data replication amongst processes even if they have no island, instance, or cluster relationship amongst each other. This replication provides performance improvement by caching expensive (shared) Java objects no matter which application produced them, and also provides availability improvement in case the sources (for example, database, an external application) required to re-create the Java objects are down. Further, if an object is updated or invalidated in one process, it is also updated or invalidated in all other associated processes. This distributed management allows a system of processes to stay synchronized, without the overhead of centralized control. Moreover, the Java Object Cache also supports versioning of objects, thus allowing different applications to have different versions of an object, which is especially useful during application upgrades.

The Java Object Cache supports two modes of operation: local mode and distributed mode. Using local mode, objects are isolated to a single Java VM process and are not shared. Using distributed mode, the Java Object Cache can propagate object changes - including invalidations, destroys, and replaces- through the cache's messaging system to other communicating caches running either on a single system or across a network (the Java Object Cache messaging system is built on top of TCP/IP).

Thus, while the primary focus of the Java Object Cache is performance improvement, it does indeed have the side effect of improved scalability and availability, since the contents of the cache are available for results computation even when the back-end server is down.

WebLogic Server does not have any feature comparable to the Java Object Cache.

Dynamic Monitoring System (DMS)

Gathering meaningful performance metrics on a deployed application server is essential for an administrator to troubleshoot bottlenecks, identify resource availability issues, and tune the application server. Oracle Application Server provides such a monitoring framework called Dynamic Monitoring Service.

DMS has been instrumented into a number of Oracle Application Server components including the Oracle HTTP Server, OC4J, OracleAS Portal, Oracle SOAP, and JServ. By publishing key metrics within these components and others, DMS provides a comprehensive view into the performance of applications managed by Oracle Application Server.

For instance, metrics such as the number of currently active requests in the Oracle HTTP Server, milliseconds required to parse the incoming request in the OC4J Servlet Engine, total free memory in the JVM, and numerous operating system metrics are published by DMS and displayed through Application Server Control. Since clients such as OEM retrieve DMS data via HTTP connections, these metrics can also be displayed through a browser.

While DMS is built into Oracle Application Server, it is also available as a monitoring framework for developers to utilize when building their own applications. DMS enables application developers to measure and export customized application specific performance metrics, thus making the application easier to support by administrators, developers, and support analysts.

There is a Java API called Java Management Extensions (JMX) that is in some ways similar to DMS and in other ways complimentary to DMS. WebLogic Server has been providing some support for JMX. Both DMS and JMX are being reviewed by the Java Community for possible inclusion into specifications.

Active Components for J2EE (AC4J)

The existing J2EE framework provides a very productive and scalable environment to author and deploy transaction-based, short-lived applications. However, it does not yet fully address emerging E-business requirements of long-lived interactions between autonomous applications. Further, as Web Services proliferate within organizations, Web Services will need to communicate with other Web Services in a loosely coupled environment, over a long period of time, without limiting resources, and surviving abnormal system crashes. Long-lived interactions between autonomous application components and Web Services require that all participants act as peers and communicate in an asynchronous and reliable fashion. To address these issues, Oracle Application Server introduces Active Components for J2EE (AC4J), a programming framework for developing loosely coupled applications, which are consistent, scalable, and recoverable.

AC4J introduces the concept of loosely coupled beans, known as Active Enterprise Java Beans. An AC4J is a standard EJB with the following important features:

• Autonomous Peer Model - With AC4J, each application, when interacting with another application, exists as an autonomous peer. The responding application may choose to ignore the request, or to execute one or more functions on behalf of the requestor (possibly different than the one that the requestor asked for), before responding to the initiating application. As peers, both applications can make requests to each other, but neither can require submission from the other. Neither application can assume control over the resources that its peer application owns.

  To support this programming model, Oracle Application Server provides reliable asynchronous, disconnected, one way, or request/response type interactions between Active EJBs.

• Declarative Specification - AC4J makes this entire paradigm easy to program allowing users to declaratively specify a number of pieces of information by simply adding attributes to the EJB deployment descriptor. When deployed, Oracle Application Server provides a runtime environment that automatically provides a number of services for these components.

  AC4J hides queues/topics and related JMS constructs from applications, provides automatic definition of communication message formats, and packs/unpacks messages, automatic routing of service requests to the appropriate service provider, automatic security context propagation, authorization and identity impersonation, automatic exception routing and handling, which is integrated in the EJB framework and automatic tracking and documenting of the computation progress of Active EJBs.

• Transactional Data Driven Execution of EJB Applications - AC4J also provides composite matching on available data based on specified rules, which describe under which conditions these data can fire which EJB method. Coupled with the transparent scheduling and activation of EJBs and execution of their methods that this provides, AC4J enables transactional data driven execution of EJBs.

• Long-Running Transactions - Since the communication between the various services and the associated tasks being performed can take a very long period of time, AC4J provides automatic durability of J2EE computational state in a portable way, automatically passivating and activating state as necessary.

• Sophisticated Capabilities - Further, with AC4J, Oracle Application Server automatically manages load balancing and scalability transparently to the applications, provides conversational state and globally visible identity (ActiveHandle); supports parallel and incremental invocation of Active EJB methods and synchronization on their results (fork and join operations); and supports restart-ability of Active EJB business method(s) in the case of system or application failures while monitoring and enforcement of application consistency.

There is no AC4J-equivalent feature available in WebLogic Server.

Oracle Application Server TopLink (OracleAS TopLink)

In an enterprise Java environment, one of the most formidable challenges is storing business objects and components in a relational database (RDB). OracleAS TopLink makes application development more productive by offering an easy to use mapping workbench that maps the Java objects to relational databases and by simplifying one of the most difficult aspects of developing applications - persisting information to the database. Using OracleAS TopLink, developers gain the flexibility to map objects and Enterprise Java Beans to a relational database schema with minimal impact on ideal application design or database integrity. The result: developers focused on addressing business needs rather than building infrastructure. OracleAS TopLink is built on JDBC and is portable across any JDBC-compliant database, including Oracles Database, DB2, SQL Server, Sybase, Informix, and Microsoft Access.

The OracleAS TopLink solution offers three key benefits:

• Mature Design, Flexibility and Performance - OracleAS TopLink provides a rich set of performance optimization and scalability features. Performance is addressed with caching techniques that minimize database and network traffic while always leveraging optimizations provided by JDBC and the databases.

• Simplified Application Development - OracleAS TopLink makes application development more productive by offering an easy to use mapping workbench that maps the Java objects to relational databases and by simplifying one of the most difficult aspects of developing applications - persisting information to the database.

• Optimization of Resources - With OracleAS TopLink, an application development team can focus on building the application rather than building infrastructure.

In essence, OracleAS TopLink offers the best solution in the market to perform Java-to-relational database object-relational mapping. With OracleAS TopLink, Oracle has blended the Java world and the relational database world in the best way possible, and solved one of the greatest challenges facing J2EE developers: productively mapping their Java objects and entity beans to a relational database.

With Oracle Application Server 10g, OracleAS TopLink is an integrated component of Oracle Application Server. Specifically, the OracleAS TopLink framework is integrated with the Oracle Containers for J2EE, and the OracleAS TopLink mapping Workbench is integrated with JDeveloper.