| Oracle® Application Server Migrating from JBoss 10g Release 3 (10.1.3.1.0) Part Number B25219-02 |
|
|
View PDF |
| Oracle® Application Server Migrating from JBoss 10g Release 3 (10.1.3.1.0) Part Number B25219-02 |
|
|
View PDF |
JBoss 3.2.6 and Oracle Application Server are based on J2EE 1.3 architectures and platform independent. JBoss is an Open Source application server using the Java Management Extension (JMX) infrastructure. Oracle Application Server has a new lightweight, robust J2EE container that supports the J2EE 1.3 standard APIs.
This chapter identifies major differences between JBoss 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 and compares the JBoss and Oracle Application Server products.
JBoss 3.2.6 provides the following components and functions:
JMX - provides integration of containers, modules and plugins
JBossServer - EJB container
JBossTX - JTA transactions
JBossMQ - JMS messaging
JBossCMP - Container Managed Persistence
JBossSX - JAAS security
Like JBoss, 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 Containers for J2EE (OC4J) a lightweight, scalable J2EE container written in Java, and is J2EE 1.3 certified. OC4J provides support for the following:
Servlets 2.4
JSP 2.0
EJB 2.1 and 3.0 (Complete EJB 3.0 and JPA implementation)
Oracle Application Server is designed specifically to run 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:
Management and security
E-business integration
Support for wireless clients
Performance caching
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 "High Availability and Load Balancing" in this chapter detail the components in and characteristics of Oracle Application Server.
This section describes and compares the architectures of JBossand Oracle Application Server.
As an Open Source application server, JBoss provides a basic level of function and the user adds other components to gain additional functionality. For example, JBoss does not provide an out of the box HTTP server. Some JBoss 3.2.6 components are:
JMX provides mangement and monitoring of software and hardware. There are three levels to the JMX model:
Instrumentation - provides resource management through MBeans
Agents - control and exposure of managed resources
Distributed Services - defines the interfaces required for JMX management applications or managers
In JBoss, JMX acts as an integration bus between the various components present in the application server.
This section describes components and several concepts that are specific to Oracle Application Server.
See Also:
Oracle Application Server Concepts
Oracle Application Server Administrator's Guide
Oracle Application Server Containers for J2EE User's Guide
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, can have 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. The 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:
Figure 2-1 Oracle Application Server Component Relationships
An OC4J instance is a logical instantiation of the OC4J implementation in Oracle Application Server. This implementation is based on Java 2 Enterprise Edition (J2EE) 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 also supported). It has a lower disk and memory footprint than previous Oracle Application Server Java environments 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 11 Application Server Control Console 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 "High Availability and Load Balancing".
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 Console 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. 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. For more information, refer to the Oracle Application Server Web Cache Administrator's Guide..
Oracle Enterprise Manager 11 Application Server Control Console provides a web-based interface for managing Oracle Application Server components and applications. Using the Application Server Control Console, you can do the following:
monitor OracleAS components, OracleAS middle tier and Infrastructure instances, OracleAS middle tier clusters, 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
For more information on Oracle Enterprise Manager and its two frameworks, see the Oracle Enterprise Manager 10g documentation.
See Also:
Oracle Application Server Administrator's Guide - provides descriptions on Application Server Control Console and instructions on how to use it.In Oracle Application Server 10g, 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:
Product Metadata Service
OracleAS Infrastructure stores all application server metadata required by OracleAS middle tier instances. This data is stored in an Oracle database, thereby leveraging the robustness of the database to provide a reliable, scalable, and easy-to-manage metadata repository.
Security Service
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.
Management 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 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:
management metadata
security metadata
product metadata
Table 2-1 shows the Oracle Application Server components that store and use these types of metadata during application deployment.
Table 2-1 Metadata and Infrastructure Components
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:
J2EE and Web Cache: Installs Oracle HTTP Server, OC4J, Oracle Application Server Web Cache, Web Services, Datatags, and Oracle Enterprise Manager 11 Application Server Control Console.
Portal and Wireless: Installs all components of J2EE and OracleAS Web Cache, plus UDDI, Oracle Application Server Portal, Oracle Application Server Syndication Services, Oracle Ultra Search, and Oracle Application Server Wireless.
Business Intelligence and Forms: Installs all components of J2EE and Oracle Application Server Web Cache, Oracle Application Server Portal, and Oracle Application Server Wireless, plus Oracle Application Server Forms Services, Oracle Reports, Oracle Business Intelligence Discoverer, and Oracle Application Server Personalization.
Integration components, such as Oracle Application Server Integration Business Activity Monitoring, Oracle Application Server Integration 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.Oracle Identity Management provides an infrastructure for the security lifecycle of applications and entities in Oracle Application Server. Some components that make up Identity Management are:
Oracle Internet Directory
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 Oracle 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.
Oracle Virtual Directory
Oracle Virtual Directory facilitates the integration of applications into existing identity infrastructures. Oracle Virtual Directory accomplishes this integration without requiring changes to exisiting directories or user repositories, allowing enterprises to deploy these services quickly without having to deal with the issues of data ownership and representation. Oracle Virtual Directory can also provide multiple application centric views of directory information optimized for the specific needs of individual applications.
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 JBoss and Oracle Application Server.
JBoss provides clustering support through the embedded Tomcat service. Load Blancing is accomplished through the use of third-party load balancers.
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:
Process Monitoring – Using the Oracle Process Manager and Notification Server system provides for process death detection and process restarting in the event that problems are detected for monitored processes.
Configuration Cloning – Using the Distributed Configuration Management features that uses a Oracle Application Server Metadata Repository for configuration information provides distributed and managed configuration for Oracle Application Server instances and for Oracle Application Server instances that are part of a cluster.
Data Replication – Using OC4J instances with OC4J islands that provide Web application level stateful session replication, and using EJB sessions, data is replicated across processes within an Oracle Application Server instance and across different Oracle Application Server instances that may reside on different hosts when using Oracle Application Server Clusters. This allows stateful session based applications to remain available even when processes within an Oracle Application Server instance become unavailable or fail.
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.
An Oracle Application Server Cluster (OracleAS Cluster) is made up of one or more OracleAS instances (see Figure 2-2 ). 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 Administrator's Guide
Figure 2-2 An OracleAS Cluster Using OracleAS Web Cache for Load Balancing
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-3). 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 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.
Note:
Use of EJB replication (EJB clusters) for high availability is independent of OracleAS Clusters and can involve multiple application server instances installed across nodes that are or are not part of OracleAS Clusters.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.
See Also:
Oracle Application Server Containers for J2EE User's Guide
Oracle Containers for J2EE Enterprise JavaBeans Developer's Guide
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 roundrobin 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.
See Also:
Oracle Application Server Web Cache Administrator's GuideSeveral 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 while 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.
While 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 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 JBoss and Oracle Application Server.
JBoss 3.2.6 is a J2EE compliant application server. It supports the following J2EE API specifications:
Oracle Containers for J2EE (OC4J) is fully certified with J2EE 1.3. Table 2-2 lists the J2EE technologies and the level of support provided by Oracle Application Server and JBoss:
Table 2-2 J2EE Technology Support
| J2EE Technology | Version Supported by JBoss 3.2.6 | Version Supported by Oracle Application Server 10g Release 3 (10.1.3.1.0) |
|---|---|---|
|
JDK |
1.3 |
1.4 and 1.3 |
|
Servlets |
2.3 |
2.4 |
|
JSPs |
1.2 |
2.0 |
|
EJBs |
2.0 |
2.1 and 3.0 (Complete EJB 3.0 and JPA implementation) |
|
JDBC |
2.0 |
3.0 |
|
JNDI |
1.2 |
1.2 |
|
JTA |
1.0.1 |
1.0 |
|
JMS |
1.0 |
1.1 |
|
JavaMail |
1.2 |
1.2 |
|
JAF |
1.0.1 |
1.0.1 |
|
JAXP |
1.0.1 |
1.2 |
|
JCA |
1.0 |
1.5 |
|
JAAS |
1.0 |
1.0 |
Note:
Oracle Application Server OC4J is installed with JDK 1.4.1. However, OC4J can also work with JDK 1.3.x for this version, 10g Release 3 (10.1.3.1.0), of Oracle Application Server.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 JBoss and Oracle Application Server.
JBoss does not provide development tools, but uses Open Source tools such as ANT.
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:
Web application development
Java client application development
Java in the database
Component-Based Development with JavaBeans
Simplified database access
Visual Integrated Development Environment
Complete J2EE 1.3 support
Automatic generation of .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 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 TopLink, an object-relational mapping tool, also comes with Oracle Application Server. For more information, see Oracle TopLink Developer's Guide.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 OC4J.
A graphical management console, integrated with Oracle Enterprise Manager 11 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. Oracle Enterprise Manager 11 Application Server Control Console is the preferred administration environment over the command line tool as Application Server Control Console provides a more integrated set of administration services.
