Skip Headers
Oracle® Application Server 10g Migrating From WebLogic
10g Release 3 (10.1.3)
B16027-01
  Go To Documentation Library
Home
Go To Product List
Solution Area
Go To Table Of Contents
Contents
Go To Index
Index

Previous
Previous
Next
Next
 

A Additional Features

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

A.1 Migrating Web Services

Before JAX-RPC was formalized as a mandatory J2EE 1.4 API, Web services were not standardized in the Java specifications. Each application server vendor had its own way of programming Web services (both server and client). Apache Axis, provided some portability between different vendors as it is a simple library that can run in any J2EE 1.3 compliant container. Axis is well adopted even though it lacks support for WS-* standards. If your WebLogic Web service is written using Apache Axis, you should be able to deploy it in Oracle Application Server 10g Release 3 (10.1.3) with little modification, if any.

Ideally, JAX-RPC as a standard should be portable. The implementation class, service endpoint interface, and the WSDL should be sufficient to deploy a Web service between different application servers. However, due to the complexity of the serialization/deserialization of SOAP, most of the time, a Web service needs to be "reassembled" from the top down. Oracle Application Server provides a utility to ease this task. The WebServicesAssembler utility accepts a WSDL and creates the requisite service endpoint interface (SEI) using its genInterface command. You can then fill in the implementation for the Web service for any required architecture, such as Java classes. To assemble the service, the utility is invoked with its topDownAssemble command. A EAR file is generated.

Even if a seamless migration is the ideal solution, "rewriting" Web services is not necessarily as complex as its appears. The critical parts to consider are the implementation class that contains the business logic and the WSDL that exposes this business logic as a Web service. Using the top down approach with the WebServicesAssembler utility allows a Web service's artifacts to be generated from a WSDL for Oracle Application Server.


See:

Oracle Application Server Web Services Developer's Guide for information on using the top down approach with WebServicesAssembler.

For migrating Web services that are compliant with J2EE 1.4 specifications to Oracle Application Server, only modifications to proprietary WebLogic Server API need to be made. The SEI and Impl class can be used without modification. The WebLogic Server proprietary API are usually those that lookup data or objects, such as accessing a HTTP request from a Web service implementation object. The proprietary API would usually have package names starting with weblogic.* . They would have to be replaced with equivalent Oracle API.

A.2 Java Messaging Service (JMS)

Oracle Application Server 10g supports JMS 1.1 and WebLogic Server 7.0 supports JMS 1.0.2. Table A-1 highlights some of the key JMS features supported by both application servers.

Table A-1 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

Fail over of Persisted JMS Messages

Yes

No

Message Payloads:

Structured Datatypes, Unstructured Datatypes, Relational Data, Text, XML, Objects, Multimedia Data

Yes

Yes

Message Transports:

SOAP, Oracle Net

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:

The following apply to Oracle Application Server 10g Release 3 (10.1.3):

A.2.1 Oracle JMS (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, Oracle Net, 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 fail over of persisted messages pertaining to a server failure. Further, it provides fail over 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 fail over 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.

A.3 Oracle TopLink

In an enterprise Java environment, one of the most formidable challenges is storing business objects and components in a relational database (RDB). Oracle 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 Oracle 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. Oracle 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 Oracle TopLink solution offers three key benefits:

In essence, Oracle TopLink offers the best solution in the market to perform Java-to-relational database object-relational mapping. With Oracle 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, Oracle TopLink is an integrated component of Oracle Application Server. Specifically, the Oracle TopLink framework is integrated with the Oracle Containers for J2EE, and the Oracle TopLink Workbench is integrated with Oracle JDeveloper.