|
Oracle® Application Server 10g Migrating From WebLogic
10g Release 3 (10.1.3) B16027-01 |
|
 Previous |
 Next |
|
Oracle® Application Server 10g Migrating From WebLogic
10g Release 3 (10.1.3) B16027-01 |
|
|
Previous |
Next |
Although WebLogic Server and Oracle Application Server are both J2EE servers that support J2EE 1.3 or 1.4 features (depending on WebLogic Server version), both application servers have intrinsic differences ranging from product packaging to runtime architecture. This chapter seeks to discuss these differences and is organized as follows:
This section describes and compares the overall architectures of WebLogic Server and Oracle Application Server.
The following table provides the specific level of support for J2EE standards provided by Oracle Application Server and WebLogic Server:
Table 2-1 J2EE Support in Oracle Application Server and WebLogic Server
| Product | J2EE 1.3 | J2EE 1.4 |
|---|---|---|
|
Oracle Application Server version |
9.0.4 10.1.2 |
10.1.3Foot 1 |
|
WebLogic Server version |
7.0 8.1 |
9.0 BetaFoot 2 |
The discussion in this guide focuses on Oracle Application Server 10g Release 3 (10.1.3) and WebLogic Server 7.0 and 8.1.
WebLogic Server has several components and concepts peculiar to it. Each WebLogic Server can be configured and deployed either as a Managed Server or an Administration Server. A Managed Server hosts and executes the application logic deployed in it when requests are received from clients. An Administration Server configures and monitors Managed Servers but does not host applications. Figure 2-1 depicts the components in WebLogic Server and their interactions.
In any node, more than one Managed Server can exist. Each Managed Server is a Java process (JVM) executing J2EE containers (Web and EJB). An Administration Server, which is also a Java process, is required to propagate configuration information to Managed Servers when they start-up. The configuration information is stored in the file system on the Administration Server node.
The Administration Server is also used to monitor and log information about individual Managed Servers and the entire WebLogic domain. A WebLogic domain can consist of standalone Managed Servers, clusters of Managed Servers, and one Administration Server. If the Administration Server goes offline, client requests can still be serviced by the Managed Servers. However, configuration information is not available for new Managed Servers to start-up, and monitoring services are not available for server clusters. The Administration Server does not have automatic fail over or replication. Configuration data for the WebLogic domain has to be manually backed up. The Administration Server functions can be accessed through a console GUI (remotely over HTTP) or a command line utility.
In order for the Administration Server to start Managed Servers remotely, a Node Manager must be running on each node where there are Managed Servers. This Node Manager is a Java program executing in the background as a UNIX daemon or Windows service. With the Node Manager, the Administration Server can also kill a Managed Server if the latter hangs or does not respond to commands from the former.
WebLogic Server can also be set up to run as a Web server. In this mode, it supports HTTP 1.1 and resolves client requests to Managed Servers based on the settings in the XML configuration files. Instead of WebLogic Server, third-party proxy plug-ins can also be used for servicing HTTP requests. Supported plug-ins are Apache, Netscape, and Microsoft IIS.
|
Note: For a discussion on WebLogic Server clustering, see Section 2.3.1, "WebLogic Server Support for High Availability and Load Balancing" |
This section describes components and several concepts peculiar to Oracle Application Server. The discussion here provides an overview scope.
|
See Also: Oracle Application Server Concepts, Oracle Application Server Administrator's Guide, Oracle Application Server High Availability Guide Oracle Application Server Containers for J2EE User's Guide. |
The J2EE server implementation in Oracle Application Server is called Oracle Containers for J2EE (OC4J). OC4J is a pure Java implementation. It runs on the standard JDK and is extremely lightweight with a small foot print. OC4J provides high performance and scalability, and is simple to deploy and manage. With Oracle Application Server 10g Release 3 (10.1.3), OC4J supports J2EE 1.4 APIs. Figure 2-3 provides an architectural view of the J2EE component layers in Oracle Application Server.
This migration guide seeks to help you understand the migration challenges you may face when migrating your J2EE applications from WebLogic Server to Oracle Application Server 10g Release 3 (10.1.3).
|
Note: In this document, where WebLogic Server is mentioned without a version number, WebLogic Server 7.0 and 8.1 are implied. Otherwise, a version number is explicitly mentioned. |
An OracleAS instance is a runtime occurrence of an installation of Oracle Application Server. An Oracle Application Server installation has a corresponding Oracle home where the Oracle Application Server files are installed. Each Oracle Application Server installation can provide only one OracleAS instance at runtime. A physical node can have multiple Oracle homes, and hence, more than one Oracle Application Server installation and OracleAS instance.
Each OracleAS instance consists of several interoperating components that enable Oracle Application Server to service user requests in a reliable and scalable manner. These components are:
Oracle Application Server contains two listeners: Oracle HTTP Server (based on the Apache open source project) and the listener that is part of OC4J, which runs in a separate thread of execution. Each OracleAS instance has one Oracle HTTP Server.
The OC4J listener listens to requests coming from the mod_oc4j module of the Oracle HTTP Server and forwards them to the appropriate OC4J process. From a functional viewpoint, the Oracle HTTP Server acts as a proxy server to OC4J, wherein all servlet or JSP requests are redirected to OC4J processes.
mod_oc4j communicates with the OC4J listener using the Apache JServ Protocol version 1.3 (AJP 1.3). mod_oc4j works with the Oracle HTTP Server as an Apache module. The OC4J listener can also accept HTTP and RMI requests, in addition to AJP 1.3 requests.
The following diagram depicts Oracle HTTP Server and other Oracle Application Server runtime components in a single instance of Oracle Application Server.
Figure 2-2 Components of an OracleAS Instance
An OC4J instance is a logical instantiation of the OC4J implementation in Oracle Application Server. This implementation is Java 2 Enterprise Edition (J2EE) 1.4 complete and written entirely in Java. It executes on the standard Java Development Kit (JDK) 1.4.2 and 5.0 Java Virtual Machine (JDK 5.0 is installed with Oracle Application Server). It has a lower disk and memory footprint than other Java application servers. Note that each OC4J instance can consist of more than one JVM process where each process can be executing multiple J2EE containers. The number of JVM processes can be specified for each OC4J instance using the Oracle Enterprise Manager 10g Application Server Control Console GUI.
OC4J can be installed and run in standalone configuration. In this configuration, the OC4J listener directly accepts client requests as Oracle HTTP Server is not installed. Another component that is not installed is the Oracle Process Manager and Notification Server, which performs process monitoring and management functions. Hence, in standalone configurations, OC4J is unmanaged.
Figure 2-3 J2EE Architecture in Oracle Application Server
The logical architecture of an OC4J instance, as depicted in Figure 2-3, consists of the following components:
JMX
The Application Server Control Console user interface is built on a JMX-compliant client that can be used to completely manage and monitor an OC4J instance. The JMX functionality provided through Application Server Control Console is enabled through Java components known as MBeans. An MBean, or managed bean, is a Java object that represents a JMX manageable resource. MBeans are defined in the J2EE Management Specification (JSR-77), which is part of the J2EE 1.4 specification as published by Sun Microsystems. For more information on MBeans, see Oracle Application Server Containers for J2EE Configuration and Administration Guide and Oracle Containers for J2EE Services Guide.
Web Services
OC4J provides full support for Web Services in accordance with the J2EE 1.4 standard, including JAX-RPC 1.1 (WebLogic Server 8.1 supports up to JAX-RPC 1.0). Web services interoperability is also supported. See Oracle Application Server Web Services Developer's Guide.
EJB, Servlet, JCA containers
OC4J implements the full J2EE 1.4 container functionality for EJB, servlet, and JCA. It provides clustering features to enable container components for availability and scalability.
Oracle TopLink persistence layer
OracleAS TopLink provides a Java object-to-relational mapping persistence architecture. It provides a highly flexible and productive mechanism for storing Java objects and EJBs in relational database tables enabling developers to focus on pure object-oriented design and methodologies. In this release of Oracle Application Server, EJB container-managed persistence is integrated with OracleAS TopLink. OracleAS TopLink container-managed persistence is the default container-managed persistence provider. Rich user interface tools in OracleAS TopLink Mapping Workbench and Oracle JDeveloper 10g allow developers to configure object-relational mapping quickly and easily. For existing container-managed EJBs, a migration utility is provided to automate migration to OracleAS TopLink container-managed persistence. See Section A.3, "Oracle TopLink", Oracle Application Server TopLink Getting Started Guide for more information on OracleAS TopLink.
Oracle Application Server allows several OC4J instances to be clustered together as part of an Oracle Application Server Cluster for scalability and high availability purposes. When OC4J instances are clustered together, they have a consistent configuration and the same applications deployed throughout the instances. A more in-depth discussion on clustering is found in Section 2.3.2, "Oracle Application Server Support for High Availability and Load Balancing".
Each OracleAS instance has an OPMN component, which performs monitoring and process management functions of processes in that instant. OPMN manages the processes in an OracleAS instance to enable startup, death-detection, and recovery of processes.
OPMN components in separate OracleAS instances can also send messages to each other to enable each OPMN to be aware of the components in the other OracleAS instances. When OPMN performs such a role, the OracleAS instances are managed by OPMN together as a cluster. Such a cluster is called an Oracle Application Server Cluster (OracleAS Cluster). (See Section 2.3.2, "Oracle Application Server Support for High Availability and Load Balancing" for more details on clusters.)
OPMN also communicates and interfaces with Application Server Control Console to provide a consolidated interface for monitoring, configurating, and managing Oracle Application Server. Some administrative tasks can also be accomplished using an OPMN command line utility. Oracle HTTP Server, and OC4J instances use a subscribe-publish messaging mechanism to communicate with the OPMN service. For process-level fail over and availability, the process that implements the OPMN service has a shadow process that restarts the OPMN process if it fails.
Oracle Enterprise Manager 10g Application Server Control Console (Application Server Control Console) provides a Web-based interface for managing Oracle Application Server components and applications. It is deployed by default as an application in OC4J. Using the Application Server Control Console, you can do the following:
monitor OracleAS components, OracleAS instances, OracleAS clusters, Oracle HTTP Server, and deployed J2EE applications and their components
configure Oracle Application Server components, instances, clusters, and deployed applications
operate OracleAS components, instances, clusters, and deployed applications
manage security for OracleAS components and deployed applications
provide performance metrics for OC4J instances and applications
For more information on Oracle Enterprise Manager and its two frameworks, see Oracle Enterprise Manager Concepts.
|
See Also: Oracle Application Server Administrator's Guide - provides descriptions on Application Server Control Console and instructions on how to use it. |
The following table provide the specific levels of support for Web services standards provided by Oracle Application Server 10g Release 3 (10.1.3) and WebLogic Server 7.0 and 8.1:
Table 2-2 Web Services Standards Supported
|
|
Oracle Application Server 10g Release 3 (10.1.3) | WebLogic Server 7.0
|
WebLogic Server 8.1 |
|---|---|---|---|
|
WS-I Basic Profile |
1.0, 1.1 |
Pre 1.0 |
1.0 |
|
WSDL |
1.1 |
1.1 |
1.1 |
|
SOAP |
1.1/1.2 |
1.1/1.2 incoming 1.1 outgoing |
1.1/1.2 |
|
WS-Reliability |
1.0 |
Not Supported |
Not Supported |
|
WS-Security |
Following from version 1.0 are supported:
|
Not Supported |
Following from version one 1.0 are supported:
|
|
UDDI |
2.0 |
2.0 |
2.0 |
In addition, consider the following:
Oracle Application Server supports Apache Axis. If a WebLogic Server application is running Axis, the same application should be deployable in Oracle Application Server provided no proprietary modifications were made to the standard Axis library.
WebLogic Web services are packaged as standard J2EE enterprise applications; deploying a Web service is the same as deploying an enterprise application.
Optional JAX-RPC datatype is support by both Oracle Application Server and WebLogic Server.
WebLogic Server uses ANT autotype and servicegen tasks. These present some limitations. autotype does not comply with the JAX-RPC specification if the data type is a complexType, the complexType contains a single sequence, or the sequence contains a single element with maxOccurs greater than 1 or is unbounded. The JAX-RPC specification, in turn, states that this type of XML Schema data type should map to a Java array with a pair of setter and getter methods in a JavaBean class. WebLogic Web services do not adhere to this last part of the specification.
REST style Web services, which uses XML documents instead of SOAP envelopes, is supported by Oracle Application Server.
This section describes high availability and load balancing and their importance to application server operation. It compares the methodologies for each in WebLogic Server and Oracle Application Server.
One or more WebLogic Servers can be grouped together as a cluster. Applications can be deployed commonly in all servers in a cluster, through cluster-wide deployment, to allow client requests to be load balanced across the cluster and the applications to have fail over capabilities. In a WebLogic cluster, the entities that benefit from clustering are HTTP session states, and EJB and RMI objects. Several load balancing algorithms are used by WebLogic. These include round-robin, weight-based, and parameter-based.
|
Note: The discussion in the following sections provides an overview of the high availability and load balancing mechanisms used by WebLogic Server. For deeper details, see http://www.weblogic.com. |
Clients making requests to a WebLogic cluster can have their requests load balanced across the servers in the cluster. For this to work, a Web server installed with the WebLogic proxy plug-in or a hardware load balancer must be used. The WebLogic proxy plug-in uses a round-robin load balancing mechanism to distribute the request load. If a hardware load balancer is used, the cluster can be load balanced using the hardware's mechanism.
WebLogic Server achieves fail over for servlets and JSPs by replicating the HTTP session states of clients. When a WebLogic Server receives the very first request for a servlet or JSP, it replicates the servlet's session state to another server. The replicated session state is always kept up-to-date with the original. The WebLogic proxy plug-in returns the names of the two servers to the client through a cookie or by rewriting the URL. If the server hosting the original session state fails, the WebLogic proxy plug-in uses the information in the cookie or URL to redirect the client to the server with the replicated session state. At any one time, the cluster maintains an original and replica of each active session state. In this scenario, the session state is replicated in memory. WebLogic Server also supports replication to the file system or a database through JDBC, however, the fail over is not automatic for these replication methods.
WebLogic Server provides load balancing and fail over for EJB and RMI objects by using a JNDI service and client stubs which are both cluster-aware.
Each WebLogic Server that is a member of a cluster maintains a local JNDI tree. This tree contains information on objects deployed on the local server and around the cluster (for objects that are clusterable). If a clusterable object is deployed on more than one server, each JNDI tree reflects the existence of that object on those servers. When a clusterable object is deployed on a server, that server, through multicast, notifies the other servers in the cluster of the new deployment. The other servers' update their JNDI trees accordingly. Note that the server with the deployed object also sends the object's stub to the other servers.
When a client looks up a clusterable object in the JNDI service, the server servicing the request returns a stub of the object to the client. This stub contains information about which server(s) the object is actually deployed in. The stub also has load balancing logic to balance method calls to the object. The load balancing algorithms available are round-robin, weight-based, random, and parameter-based. From the client's point-of-view, the cluster is transparent. The JNDI look ups and load balancing are done without the client knowing that it is working with a clustered object at the server end.
In the case where a clustered object is stateful, for example, a stateful session EJB, the object's state is replicated to a second server. The replication is achieved in a similar manner as for HTTP session state. The server that is chosen to service a client's very first request replicates the object's state to another server. The client stub is updated to note this second server. If the first server fails, the stub receives an exception when it tries to invoke a method. The stub then redirects the invocation to the server with the replicated object state. This server instantiates the object with the replicated state and executes the method invocation. This server also selects another server to replicate the state to since the original server has failed. Fail over of stateful objects is achieved this way.
Fail over of stateless objects is more straightforward to achieve as state need not be replicated. Upon receiving an exception indicating that a server has failed, the client stub simply selects another server which is hosting another instance of the called object and redirects the method invocation there.
The Oracle Application Server architecture supports high availability for Oracle Application Server instances that in many cases can prevent unplanned down time for deployed applications. In general, Oracle Application Server achieves high availability through clustering and process monitoring. Clustering ensures that fail over, load balancing, and scalability are achieved for deployed J2EE applications. Additionally, monitoring of individual processes in a cluster ensures that processes are reliable. The following sections discuss how the benefits of clustering and process monitoring are attained by Oracle Application Server:
Processes in an Oracle Application Server instance are monitored by OPMN. The OPMN system provides for process death detection and process restarting in the event that component processes in an Oracle Application Server instance "hang" or "crash." Monitored components include Oracle HTTP Server and OC4J processes. Refer to Section 2.1.3.5, "Oracle Process Management Notification (OPMN) Server" for more information on OPMN.
OPMN provides the functionality for managing clustered Oracle Application Server components. The OPMN process in an Oracle Application Server instance can be configured to be aware of the availability of Oracle HTTP Server and OC4J processes in other Oracle Application Server instances. This allows OPMN to have a real-time picture of the health of all component processes in a cluster.
High availability of HTTP session state and stateful session EJBs is provided by application clustering. This type of clustering enables fail over and redundancy at the application level. For applications deployed in OC4J, objects and values in HTTP sessions and stateful session EJBs can be replicated to OC4J instances in different server nodes. These OC4J instances host the same applications. If one node fails, requests to a clustered application on that node can be directed to the a surviving node hosting that clustered application. The fail over of the application is transparent to the client. The replication of session state can be made in one of two ways:
In memory
When replication of session state is made in memory, the participating nodes can communicate in one of two ways: multicast or peer-to-peer. For multicast, session state information is multicast over a common address and port. The address and port information is specified in an application's deployment configuration file. All applications deployed with the same multicast address and port have their state information replicated to other nodes with the same application and multicast address and port specified. The number of nodes involved in the replication can be explicitly specified so that multicast traffic can be minimized.
For peer-to-peer, the session state information is unicast from one peer node to another. The participating nodes can be dynamically discovered or statically defined (OC4J standalone deployments only). For dynamic discovery, a node registers with OPMN to discover other peers and to add itself to the list of peers. State information is then replicated to each peer in the list.
In a database
Session state information can be persisted into a database. The database's JNDI datasource name is specified in an application's deployment configuration file. The replicated information is stored in three database tables, which are created the first time the database replication is invoked. The session data is stored for the duration of the session's time-to-live. Provided the database itself is protected from failures and has a backup and recovery scheme in place, persisting state information in the database allows for recovery of the information in cases where all processes and nodes participating in the cluster have failed.
|
Note: All session objects must be serializable if they are to be persisted into memory or a database. |
Within each cluster, there is no mechanism to load balance or fail over the OracleAS instances. That is, there is no internal mechanism in the cluster to load balance or fail over requests to the Oracle HTTP Server component in the instances. A separate load balancer such as OracleAS Web Cache or hardware load balancing product can be used to load balance the OracleAS instances in the cluster and fail over the Oracle HTTP Server instances in the cluster.
Smart Routing – Oracle Application Server Web Cache and Oracle HTTP Server (mod_oc4j) provide configurable and intelligent routing for incoming requests. Requests are routed only to processes and components that mod_oc4J determines to be alive, through communication with the Oracle Process Manager and Notification Server system. This smart routing mechanism load balances requests to J2EE applications deployed in clustered OC4J instances.
Oracle Application Server Java Object Cache provides a distributed cache that can serve as a high availability solution for applications deployed to OC4J. The Java Object Cache is an in-process cache of Java objects that can be used on any Java platform by any Java application. It allows applications to share objects across requests and across users, and coordinates the life cycle of the objects across processes.
Java Object Cache enables data replication among OC4J processes even if they do not belong to the same OC4J cluster, application server instance, or Oracle Application Server Cluster.
By using Java Object Cache, performance can be improved since shared Java objects are cached locally, regardless of which application produces the objects. This also improves availability; in the event that the source for an object becomes unavailable, the locally cached version will still be available.
This section compares the Java tools offered by the WebLogic Platform and Oracle Application Server.
The WebLogic development environment and Administration Console are described below.
WebLogic Workshop is a visual development environment for building and deploying Web services using Java and XML. Workshop provides a framework and set of controls to interact with EJBs, databases, JMS topics and queues, and other Web services and applications. Several of these controls are proprietary to the WebLogic Platform, in addition to the Java Web Services (JWS) file definition. A JWS file contains the logic to implement a Web service on WebLogic Server. However, JWS is not a J2EE or Web services standard and is not portable to other application services.
The WebLogic Server administrative console provides a GUI for managing the WebLogic Server domain. A WebLogic Server domain consists of one or more WebLogic Server instances (where each instance runs one or more applications) or clusters of instances. The administrative console connects to the designated administrative server running in the domain and can be used to change the configuration or run-time state on any machine in a domain. The administrative console is used to define clusters, add servers, deploy applications, configure applications, and manage Web servers, services, and resources in the domain.
This section describes development and deployment tools for creating J2EE applications. The tools are part of the Oracle Developer Suite.
Application developers can use the tools in Oracle JDeveloper to build J2EE- compliant applications for deployment on OC4J. JDeveloper is a component in Oracle Internet Developer Suite, a full-featured, integrated development environment for creating multitier Java applications. It enables you to develop, debug, and deploy Java client applications, dynamic HTML applications, Web and application server components and database stored procedures based on industry-standard models. For creating multitier Java applications, JDeveloper has the following features:
Web application development
Java client application development
Java in the database
Simplified database access
Visual Integrated Development Environment
Complete J2EE 1.4 support
Automatic generation of .ear files, .war files, ejb-jar.xml file, and deployment descriptors.
You can build applications with Oracle JDeveloper and deploy them manually, using Application Server Control Console, or with the OC4J Administration Console. Also note that you are not restricted to using JDeveloper to build applications; you can deploy applications built with IBM VisualAge or Borland JBuilder on OC4J.
|
Note: In addition to JDeveloper, Oracle Application Server TopLink, an object-relational mapping tool, also comes with Oracle Application Server. See Oracle Application Server TopLink Application Developer's Guide. |
|
Note: The Oracle JDeveloper Application Migration Assistant, a migration tool that plugs into Oracle JDeveloper, can be used to quickly identify application code that needs to be migrated. See the section "Migration Tool" on page 1-6 for more information and where to download the tool. |
Oracle Application Server provides a number of assembly tools to configure and package J2EE Applications. The output from these tools is compliant with J2EE standards and is not specific to OC4J. These include:
A WAR file assembly tool to assemble JSP, servlets, tag libraries and static content into WAR files.
An EJB assembler, which packages an EJB home, remote interface, deployment descriptor, and the EJB into a standard JAR file.
An EAR file assembly tool, which assembles WAR Files and EJB JARs into standard EAR files.
A tag library assembly tool, which assembles JSP tag libraries into standard JAR files.
Oracle Application Server also provides two different administration facilities to configure, monitor, and administer its components.
A graphical management tool, Oracle Enterprise Manager 10g Application Server Control Console, which provides a single point of administration across OracleAS Clusters, Farms, and OC4J containers.
A command line tool for performing administrative tasks locally or remotely from a command prompt. (Application Server Control Console is the preferred administration environment over this command line tool as it provides a more integrated set of administration services.)
