Oracle® Application Server 10g Migrating From WebLogic
10g Release 3 (10.1.3) B16027-01 |
|
![]() Previous |
![]() Next |
This appendix provides additional comparative information between WebLogic Server 7.0 and Oracle Application Server 10g. This information consists of:
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.
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:
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
.
The following apply to Oracle Application Server 10g Release 3 (10.1.3):
Supports JMS 1.1.
Has generic JMS JCA 1.5 resource adaptor with:
support for WebSphereMQ, Tibco JMS, SonicMQ
full MDB support
full XA support
JMX-based dynamic configuration:
no server restart for Destination
and ConnectionFactory
creation or deletion
no server restart for JMS server property changes
JMS router in Oracle Application Server provides bridge for Oracle JMS, OracleAS JMS, WebSphereMQ, Tibco JMS, SonicMQ.
Support for message filtering during routing of messages.
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.
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:
Mature Design, Flexibility and Performance - Oracle 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 - 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.
Optimization of Resources - With Oracle TopLink, an application development team can focus on building the application rather than building infrastructure.
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.