10g (9.0.4)
Part Number B10426-01
 Home |
 Contents |
 Index |
| Oracle Application Server 10g Migrating from WebSphere 10g (9.0.4) Part Number B10426-01 |
|
WebSphere 3.5.3 and Oracle Application Server are created from entirely different architectures. WebSphere is based on the IBM SanFrancisco Java application framework and its Component Broker, both of which predate J2EE standards. Oracle Application Server has a new lightweight, robust J2EE container that supports the J2EE 1.3 standard APIs.
This chapter identifies major differences between WebSphere and Oracle Application Server in terms of overall product offering, architecture, clustering and load balancing, J2EE support, and development and deployment tools.
This section describes WebSphere and Oracle Application Server products.
IBM sells a several technologies under the WebSphere marketing umbrella (for WebSphere 3.5.3). The WebSphere Application Server is the core of the WebSphere extended family of products, of which there are three versions, described below.
WebSphere Standard Edition is a servlet/JSP container layer that runs on top of an HTTP server. It works with a number of popular HTTP servers, including IBM HTTP Server, Microsoft IIS, and Netscape iPlanet server. WebSphere Standard Edition supports static HTML pages, servlets, JavaServer Pages, and XML .
WebSphere Advanced Edition contains all the features of Standard Edition, and also includes:
WebSphere Advanced Edition is IBM's core J2EE server.
WebSphere Enterprise Edition includes all of the features in Advanced Edition, and also includes:
In WebSphere Enterprise Edition, the Component Broker serves both EJBs and CORBA objects. TXSeries provides a a pure transactional environment, for applications that don't require an EJB/component-based/object-oriented programming model. Depending on your requirements, you could use either or both.
Like WebSphere, Oracle Application Server is a platform-independent J2EE application server that can host multi-tier, web-enabled enterprise applications for the Internet and intranets, and which is accessible from browser and standalone clients. It includes Oracle Application Server Containers for J2EE (OC4J) a lightweight, scalable J2EE container written in Java, and is J2EE 1.3 certified. Hence, OC4J provides support for the following J2EE 1.3 APIs:
Oracle Application Server is designed specifically for running large-scale, distributed Java enterprise applications, including Internet commerce sites, enterprise portals and high volume transactional applications. It adds considerable value beyond the J2EE standards in areas critical to the implementation of real world applications, providing an entire suite of integrated solutions that encompass:
Oracle Application Server is designed specifically for running large-scale, highly available distributed Java enterprise applications, including Internet commerce sites, enterprise portals and high volume transactional applications. It adds considerable value beyond the J2EE standards in areas critical to the implementation of real world applications, providing an entire suite of integrated solutions that encompass:
To enable these solutions to be implemented in a reliable and scalable infrastructure, Oracle Application Server can be deployed in a redundant architecture using clustering mechanisms. The sections "Architecture Comparison" and "Oracle Application Server Support for High Availability and Load Balancing" in this chapter details the components in and characteristics of Oracle Application Server.
This section describes and compares the overall architectures of WebSphere and Oracle Application Server.
The WebSphere Advanced Edition 3.5.3 consists of the following components:
IBM's HTTP Server is the Apache HTTP Server (with official product support) with SSL capability implemented by IBM, and IBM tools for managing keys, certificates, and such. The public key technology that SSL uses is patented and requires tracking for licensing purposes. The SSL support is part of IBM's value-add on top of the Apache HTTP Server open source distribution. Neither Apache nor the IBM HTTP Server provide servlet support out-of-the-box.
The Web Server Plug-in is a module that runs within the web server, using its native APIs, and forwards requests to the WebSphere Application Server. When you install WebSphere, the installation program installs a hook into the web server that intercepts HTTP requests that target a servlet (it examines the incoming URL to determine whether it is a servlet request), and redirects those requests to the servlet engine for processing. Static content is still handled solely by the HTTP Server.
The Adminsitrative Server must be running on every node that is running a WebSphere Application Server component. It performs the following functions:
The WebSphere Application Server version 3.5.x requires an Administrative Server Repository. The Administrative Server Repository is a relational database containing configuration information. This database is used to store setup, configuration, and state information about the WebSphere Application Server.
Before starting the Administrative Server, WebSphere Application Server checks for the existence of an Administrative Server Repository, which contains descriptive information about the resources that are configured to run on each node in the domain, for example, the names of application servers, the node each server is running on, the enterprise beans installed in each server, and the current state of each server.
The Administrative Server Repository enables the system administrator to manage the domain from any machine, because all configuration information is stored in a central location. Each Administrative Server has a central view of resource configuration information about in the domain. When the administrator modifies a resource configuration, the changes are seen by all administrative servers.
In WebSphere, an Application Server is the process that runs servlet and/or EJB-based applications, providing both the servlet run-time components (Servlet Engine, Web applications) and EJB run-time (EJB container). Like the Administrative Server, each WebSphere Application Server runs in its own Java Virtual Machine (JVM).
This section describes components and several concepts peculiar to Oracle Application Server. The discussion here provides an overview scope.
An OracleAS instance is a runtime occurrence of an installation of Oracle Application Server. An Oracle Application Server installation corresponds to an "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:
OracleAS contains two listeners: The 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 instance. 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 instances.
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 OracleAS.
An OC4J instance is a logical instantiation of the OC4J implementation in Oracle Application Server. This implementation is Java 2 Enterprise Edition (J2EE) complete and written entirely in Java. It executes on the standard Java Development Kit (JDK) 1.4 Java Virtual Machine, which is installed with OracleAS (JDK 1.3 is supported). It has a lower disk and memory footprint than the previous Oracle Application Server Java environment and competitive 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 Application Server Control GUI.
Oracle Application Server allows several OC4J instances to be clustered together for scalability and high availibility purposes. When OC4J instances are clustered together, they have the same configuration and applications deployed amongst them. A more in-depth discussion on clustering is found in the section "Oracle Application Server Support for High Availability and Load Balancing" below.
Each OracleAS instance has an OPMN server which performs monitoring and process management functions within that instance. This service communicates messages between the components in an OracleAS instance to enable startup, death-detection and recovery of components. This communication extends to other OPMN services in other OracleAS instances belonging to the same cluster as well, thereby allowing other instances in a cluster to be aware of active OC4J and Oracle HTTP Server processes in other OracleAS instances (in the same cluster).
The OPMN service also communicates and interfaces with Application Server Control to provide a consolidated interface for monitoring, configurating, and managing Oracle Application Server. Oracle Application Server components, Oracle HTTP Server, OC4J instances, and Distributed Configuration Manager (described below), use a subscribe-publish messaging mechanism to communicate with the OPMN service. For failover and availibility, the process that implements the OPMN service has a shadow process that restarts the OPMN process if it fails.
In order to manage and track configuration changes in the various components in each OracleAS instance, a DCM process exists in each OracleAS instance to perform those tasks. Each configuration change made to any of the components in a OracleAS instance is communicated to the DCM. DCM in turn takes note of the change and records it in the Oracle Application Server Metadata Repository in the Infrastructure database. This repository contains the configuration information for all the OracleAS instances connected to it through their respective DCMs. All OracleAS instances connecting to the same infrastructure repository in this way belong to the same OracleAS Farm. If any of the OracleAS instances fail, the configuration information can be retrieved from the repository for purposes of restarting the instance.
Each DCM also communicates with the OPMN in their respective instances to send notification events on changes in repository data. This allows OPMN to make the corresponding adjustments to the Oracle Application Server components.
OracleAS provides a caching solution with the unique capability to cache both static and dynamically generated web content. The Oracle Application Server Web Cache significantly improves the performance and scalability of heavily loaded Oracle Application Server web sites by reducing the number of round trips to the web server. In addition, it provides a number of features to ensure consistent and predictable responses. These features include page fragment caching, dynamic content assembly, web server load balancing, Web Cache clustering, and failover. Oracle Application Server Web Cache can be used as a load balancer for OracleAS instances in a cluster. Oracle Application Server Web Cache can itself be deployed in its own cluster. Refer to the Oracle Application Server Web Cache Administrator's Guide.
Oracle Enterprise Manager Application Server Control provides a web-based interface for managing Oracle Application Server components and applications. Using the Application Server Control, you can do the following:
For more information on Oracle Enterprise Manager and its two frameworks, see the Oracle Enterprise Manager documentation.
In this version of Oracle Application Server, 10g (9.0.4), the role of the Infrastructure is expanded from earlier versions. It provides a completely integrated framework for the development and deployment of enterprise applications. An OracleAS Infrastructure installation type provides centralized product metadata, security services, management services, and configuration and data repositories for the OracleAS middle tier. By integrating the Infrastructure services required by the middle tier, time and effort required to develop enterprise applications are reduced. In turn, the total cost of developing and deploying these applications is reduced, and the deployed applications are more reliable.
The OracleAS Infrastructure provides the following overall services:
OracleAS Infrastructure stores all application server metadata required by OracleAS middle tier instances. This data is stored in an Oracle9i database, thereby leveraging the robustness of the database to provide a reliable, scalable, and easy-to-manage metadata repository.
The security service provides a consistent security model and identity management for all applications deployed on OracleAS. The service enables centralized authentication using single sign-on, web-based administration, and centralized storage of user authentication credentials. The Oracle Internet Directory is used as the underlying repository for this service.
This service is used by Oracle Enterprise Manager and DCM to manage and administer OracleAS middle tier instances and the OracleAS Infrastructure. It is also used to administer clustering services for the middle tier. Oracle Enterprise Manager reduces the total administrative cost by centralizing the management of deployed J2EE applications through the OracleAS Console, which provides web pages for unified administration of OracleAS.
The components in OracleAS Infrastructure which implement the above services are:
Oracle Application Server Metadata Repository is an Oracle9i Enterprise Edition database server and stores component-specific information that is accessed by the Oracle Application Server middle tier or Infrastructure components as part of their application deployment. The end user or the client application does not access this data directly. For example, a Portal application on the middle tier accesses the Portal metadata as part of the Portal page assembly aggregation. Metadata also includes demo data for many Oracle Application Server components, such as data used by the Order Management Demo for Oracle Business Components for Java (BC4J).
Oracle Application Server metadata and customer or application data can coexist in the Oracle Application Server Metadata Repository, the difference is in which applications are allowed to access them.
The Oracle Application Server Metadata Repository stores three main types of metadata corresponding to the three main Infrastructure services described earlier in this section. These types of metadata are:
Table 2-1 shows the Oracle Application Server components that store and use these types of metadata during application deployment.
Oracle Application Server Metadata Repository is needed for all application deployments except for those using the J2EE and Web Cache install option. Oracle Application Server provides three middle tier installation options:
Integration components, such as Oracle Application Server ProcessConnect, Oracle Application Server InterConnect, and Oracle Workflow are installed on top of any of these middle tier install options.
The DCM component enables middle tier management, and stores its metadata in the Metadata Repository for both the Portal and Wireless and the Business Intelligence and Forms install options. For the J2EE and Web Cache installation type, by default, DCM uses a file-based repository. If you choose to associate the J2EE and Web Cache installation type with an Infrastructure, the file-based repository is moved into the Metadata Repository.
|
See Also:
Oracle Application Server 10g Installation Guide for information on the OracleAS installation details. |
The Oracle Identity Management components provide an infrastructure for the security lifecycle of applications and entities in OracleAS. The components that make up Identity Management are:
Oracle Internet Directory is Oracle's implementation of a directory service using the Lightweight Directory Access Protocol (LDAP) version 3. It runs as an application on the Oracle9i database and utilizes the database's high performance, scalability, and high availability.
Oracle Internet Directory provides a centralized repository for creating and managing users for the rest of the Oracle Application Server components such as OC4J, Oracle Application Server Portal, or Oracle Application Server Wireless. Central management of user authorization and authentication enables users to be defined centrally in Oracle Internet Directory and shared across all Oracle Application Server components.
Oracle Internet Directory is provided with a Java-based management tool (Oracle Directory Manager), a Web-based administration tool (Oracle Delegated Administration Services) for trusted proxy-based administration, and several command-line tools. Oracle Delegated Administration Services provide a means of provisioning end users in the Oracle Application Server environment by delegated administrators who are not the Oracle Internet Directory administrator. It also allows end users to modify their own attributes.
Oracle Internet Directory also enables Oracle Application Server components to synchronize data about users and group events, so that those components can update any user information stored in their local application instances.
OracleAS Single Sign-On is a multi-part environment which is made up of both middle tier and database functions allowing for a single user authentication across partner applications. A partner application can be achieved either by using the SSOSDK or via the Apache mod_osso module. This module allows Apache (and subsequently URLS) to be made partner applications.
OracleAS Single Sign-On is fully integrated with Oracle Internet Directory, which stores user information. It supports LDAP-based user and password management through Oracle Internet Directory.
OracleAS Single Sign-On supports Public Key Infrastructure (PKI) client authentication, which enables PKI authentication to a wide range of Web applications. Additionally, it supports the use of X.509 digital client certificates and Kerberos Security Tickets for user authentication.
By means of an API, OracleAS Single Sign-On can integrate with third-party authentication mechanisms such as Netegrity Site Minder.
OracleAS Certificate Authority (OCA) is a component of the Oracle public key infrastructure (PKI) offering that allows you to create and manage X.509v3 digital certificates for use in Oracle or third-party software. OCA is fully standards-compliant, and is fully integrated with Oracle Application Server Single Sign-On and Oracle Internet Directory. OracleAS Certificate Authority provides web-based certificate management and administration, as well as XML-based configuration. It leverages the Identity Management infrastructure, high availability, and scalability of the Oracle9i platform.
This section defines and describes clustering and load balancing and their importance to application server operation, It compares the methods for high availability (mainly through clustering) and load balancing used in WebSphere and Oracle Application Server.
WebSphere provides clustering and load balancing support through its Administrative Console, with cloning and workload management services.
Clustering is implemented in WebSphere with a mechanism called cloning, available in the Administration system. Cloning enables you to create multiple copies of an application server, based on a server that you have already configured.
The clone has the same structure and attributes as the application server on which it is based, but it is not associated with any node, and does not correspond to any real server process running on any node.
WebSphere Application Server supports cloning for servlet engines, Web applications, and servlets for workload management, load balancing, and failover. The servlets, EJBs, and Web resources are shared by the clones, but each clone uses its own JVM to run the application code. This provides identical, yet independent processes for the application to run in.
The workload management service improves the scalability of the application server environment by grouping multiple application servers into application server groups. Clients then access these application server groups as if they were a single server, and the workload management service distributes the workload among the application servers in the application server groups. An application server can belong to only one application server group. WebSphere workload management supports load balancing for stateless servlets and stateless session beans, and provides a failover mechanism for stateful servlets and stateful session beans.
Servlet load balancing is performed by a servlet redirector. The servlet redirector runs on the Web server in front of the application servers. The redirector balances workload across the servlet engines running in multiple application servers behind the Web server. When a web server HTTP session asks to invoke a servlet, the redirector transfers the request to a servlet engine.
The EJB component workload manager balances the load between Java objects (servlets to EJB components, EJB components to EJB components and stand-alone Java clients to EJB components). For example, when a servlet needs data or begins a transaction through an EJB component, the EJB component workload manager transfers the request to an EJB container (an instance of WebSphere Application Server) or a remote EJB handler.
Oracle Application Server is designed with several high availability and load balancing mechanisms. These mechanisms ensure that failover and scalability are achieved at the Infrastructure and middle tier levels. For failover, clusters of similar OracleAS components can be created. These clusters offer redundancy for similar components.
This section describes the clustering and load balancing concepts and capabilities of applicable components in Oracle Application Server.
The Oracle Application Server architecture supports high availability in the middle tier that in many cases can prevent unplanned down time for deployed applications. This section provides an overview of the architecture of an Oracle Application Server instance and shows some of the mid-tier high availability features.
Within each Oracle Application Server instance, the following features provide high availability within the instance, and for any clusters that the instance is a part of:
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.
An Oracle Application Server Cluster (OracleAS Cluster) is made up of one or more OracleAS instances (see Figure 2-3). All OracleAS instances in the cluster have the same configuration. The first OracleAS instance to join a cluster has its configuration replicated to the second and later instances when they join. In addition to the configuration, deployed OC4J applications are also replicated to the newer instances. Information for the replicated configuration and applications is retrieved from the OracleAS Metadata Repository used by the cluster.
Within each cluster, there is no mechanism to load balance or failover the OracleAS instances. That is, there is no internal mechanism in the cluster to load balance or failover 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 failover the Oracle HTTP Server instances in the cluster.
Several OracleAS Clusters and standalone OracleAS instances can be further grouped into an OracleAS Farm. The clusters and instances in this farm share the same OracleAS Metadata Repository. For further information on OracleAS Farms, refer to the Oracle Application Server 10g Administrator's Guide.
An important function of clustering technology in Oracle Application Server is that of reducing multicast traffic. With every server sharing its session state with every other server in the cluster, a lot of CPU cycles is consumed as overhead to replicate the session state across all nodes in the cluster. Oracle Application Server solves this problem by introducing the concept of OC4J islands, where OC4J processes (JVMs) in an OracleAS Cluster can be sub-grouped into islands. Session state of applications is replicated only to OC4J processes belonging to the same island rather than all OC4J processes in the OracleAS Cluster. Hence, state is replicated to a smaller number of processes. OC4J islands are typically configured to span across physical nodes, thereby allowing failover of application state if a node goes down.
Consider an OracleAS Cluster with four OC4J processes running in two nodes, two processes per node (see Figure 2-4). When the state of an application changes, which could occur at every request from the same client, multicast messages are sent between all four processes to update the state of that application in each process. If these four processes were to be divided into two islands of two processes across two nodes, state replication of the application would only have to occur between processess within the same island. Multicast messages would be required only between the two processes in the island instead of four, reducing replication overhead by half. As a result, network traffic and CPU cycles are reduced.
When configuring OC4J islands, you can specify the number of OC4J processes for each node that belong to each island. By doing so, you can increase or decrease the number of processes based on the capabilities of the hardware and operating system of each node. For instructions on how to configure OracleAS Clusters and OC4J islands, refer to Oracle Application Server 10g High Availability Guide.
Using OC4J, stateful session EJBs can be configured to provide state replication across OC4J processes running within an application server instance or across an OracleAS Cluster. This EJB replication configuration provides high availability for stateful session EJBs by using multiple OC4J processes to run instances of the same stateful session EJB.
EJB clusters provide high availability for stateful session EJBs. They allow for failover of these EJBs across multiple OC4J processes that communicate over the same multicast address. Thus, when stateful session EJBs use replication, this can protect against process and node failures and can provide for high availability of stateful session EJBs running on Oracle Application Server.
When EJB clustering is enabled, JNDI namespace replication is also enabled between the OC4J instances in an OracleAS Cluster. New bindings to the JNDI namespace in one OC4J instance are propagated to other OC4J instances in the OracleAS Cluster. Rebindings and unbindings are not replicated.
The replication is done outside the scope of OC4J islands. In other words, multiple islands in an OC4J instance have visibility into the same replicated JNDI namespace.
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 island, 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.
Two or more OracleAS Web Cache instances can be clustered together to create a single logical cache. Physically, the cache can be distributed amongst several nodes. If one node fails, a remaining node in the same cluster can fulfill the requests serviced by the failed node. The failure is detected by the remaining nodes in the cluster who take over ownership of the cacheable content of the failed member. The load balancing mechanism in front of the OracleAS Web Cache cluster, for example, a hardware load balancing appliance, redirects the requests to the live OracleAS Web Cache nodes.
OracleAS Web Cache clusters also add to the availability of OracleAS instances. By caching static and dynamic content in front of the OracleAS instances, requests can be serviced by OracleAS Web Cache reducing the need for the requests to be fulfilled by OracleAS instances, particularly for Oracle HTTP Servers. The load and stress on OracleAS instances is reduced, thereby increasing availability of the components in the instances.
Oracle Application Server Web Cache can also perform a stateless or stateful load balancing role for Oracle HTTP Servers. Load balancing is done based on the percentage of the available capacity of each Oracle HTTP Server, or, in other words, the weighted available capacity of each Oracle HTTP Server. If the weighted available capacity is equal for several Oracle HTTP Servers, OracleAS Web Cache uses round robin to distribute the load. Refer to Oracle Application Server Web Cache Administrator's Guide for the formula to calculate weighted available capacity.
In the case of failure of a Oracle HTTP Server, OracleAS Web Cache redistributes the load to the remaining Oracle HTTP Servers and polls the failed server intermittently until it comes back online. Thereafter, OracleAS Web Cache recalculates the load distribution with the revived Oracle HTTP Server in scope.
Several solutions exist to enable high availability for the OracleAS Infrastructure. These solutions allow for intrasite failover. They are:
The cold failover cluster solution offers a two-node hardware cluster, which are identically configured. One node is active whilst the other is passive. A hardware interconnect exists between both nodes, which run with an operating system that has clustering features. Both of these nodes access a common shared storage. A single logical IP address is also shared between the two nodes. (A unique physical IP address also exists for each node. But only the single logical IP address is visible and used by the middle tier to access the Infrastructure on the cold failover cluster.
During OracleAS Infrastructure installation, the "Oracle Home" for the installation is installed on the shared storage together with the database files. During operation, only one node is mounted on the shared storage at any one time. In the event that the active node fails, the clustering software of the passive node detects the failure and "takes over" the logical IP address. The passive node becomes the active node, mounts the shared storage, and services requests from the middle tier.
The cold failover cluster nodes can also be installed with the middle tier. In this scenario, the nodes are active-active for the middle tier and active-passive for the Infrastructure.
Whilst the cold failover cluster offers an active-passive availability configuration for the Infrastructure, the Oracle Application Server Active Clusters (OracleAS Active Clusters) solution offers active-active availability. The OracleAS Active Clusters solution is based on Oracle9i Real Application Clusters technology. It allows more than two nodes to be active in a cluster. The underlying hardware used for each node also utilizes hardware cluster technology. But the IP address take over mechanism is not used. Instead, a hardware load balancer appliance is configured in front of the OracleAS Active Clusters nodes to load balance requests to them. This load balancer has a logical IP name and address, which is/are used by the middle tier to access the Infrastructure. Oracle Net connections bypass this hardware load balancer by using an address list of nodes in the cluster. Both the hardware load balancer appliance and Oracle Net manage the failover of requests to active nodes if a node fails.
This section outlines the differences in the level of support of J2EE specifications between WebSphere and Oracle Application Server.
WebSphere 3.5.3 is a J2EE server, but is not fully J2EE 1.2 compliant. It supports the following J2EE API specifications:
WebSphere is not fully J2EE compliant, since it provides custom extensions to J2EE standards and includes non-standard packages for supporting J2EE features, such as servlet filtering and chaining, security, connection pooling and data access beans, and deployment dersciptors. An application using these extensions and packages requires code-level changes in order to migrate to Oracle Application Server or any other J2EE-compliant application server.
Oracle Application Server Containers for J2EE (OC4J) is fully certified with J2EE 1.3. Table 2-1 lists the J2EE technologies and the level of support provided by Oracle Application Server and WebSphere:
In addition to supporting these standards, Oracle Application Server provides a well-thought-out, integrated architecture for building real world J2EE applications, including implementation of standard deployment archives: JAR files for EJBs, Web Archives (WARs) for servlets and JSPs, and Enterprise Archives (EARs) for applications. This ensures smooth server interoperability.
This section compares the Java tools included with WebSphere and Oracle Application Server.
The WebSphere development environment, tools, and system administration console are described below.
VisualAge for Java is is IBM's integrated development environment (IDE) for building J2EE applications. VisualAge for Java offers remote debugging support for JSP pages and other server-side Java logic. A new Servlet SmartGuide generates servlets, JSP components, and HTML prototypes, so that developers can quickly test their code inside the IDE before deploying to a production server. Integration with IBM WebSphere Studio allows for quick addition of content to prototypes, increasing productivity for programmers and web developers. VisualAge also comes with Persistence Builder, a standalone object-relational mapper tool .
The WebSphere Studio provides a tool set for creating, managing and debugging multiplatform Web applications. It includes the following functionality:
The WebSphere Administrative Console provides a GUI for managing the WebSphere domain. A WebSphere domain consists of one or more WebSphere instances (where each instance runs one or more applications). The Administrative Console connects to one of the Administrative servers running in the domain and can be used change to the configuration or run-time state on any machine in a domain. The Administrative Console is used to manage the administrative repository, deploy applications and configure applications.
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 multi-tier 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 multi-tier Java applications, JDeveloper has the following features:
.ear files, .war files, EJB JAR file, and deployment descriptors.
You can build applications with Oracle JDeveloper and deploy them manually, using Application Server Control. 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.
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:
Oracle Application Server also provides two different administration facilities to configure, monitor, and administer OC4J.
|
 Copyright © 2003 Oracle Corporation. All Rights Reserved. |
|