Overview of WebLogic Server Deployment
Contents
See also: WebLogic 8.1 Deploying
Deployment Units
Refers to a J2EE application or a standalone J2EE module.
Deployment units may include Java classes for EJBs and servlets, resource adapters, Web pages and supporting files, XML-formatted deployment descriptors, and even other modules.
WebLogic Server supports deployments that are packaged either as archive files using the jar utility, or as exploded archive directories.
The available deployment units are:
Applications Enterprise Applications or Web Services packaged as .ear files or directories EJB Modules Enterprise JavaBeans Web Application Modules Web Applications or Web Services packaged as .war files or directories Connector Modules Resource Adapters Startup & Shutdown Startup classes and shutdown classes
Standalone Modules
J2EE provides specifications for creating standalone modules, which include Enterprise JavaBeans and resource adapter modules. WebLogic Server also supports deploying Web Services modules, which are not part of the J2EE specification.
Standalone modules generally provide parts of a larger, distributed application, but do not necessarily provide a direct user interface.
Enterprise JavaBean
Enterprise JavaBeans are reusable Java components that implement business logic and enable you to develop component-based distributed business applications. EJB modules are packaged as archive files having a .jar extension, but are generally deployed as exploded archive directories. The archive file or exploded archive directory for an EJB contains the compiled EJB classes, optional generated classes, and XML deployment descriptors for the EJB.
Resource Adapter
A Resource Adapter (also referred to as a connector) adds Enterprise Information System (EIS) integration to the J2EE platform. Connectors provide a system-level software driver that WebLogic Server can use to connect to an EIS. Connectors contain both the Java classes, and if necessary, the native components required to interact with the EIS.
Note: Resource Adapters cannot be deployed as exploded archive directories.
Web Services
Web Services are a type of service that can be shared by and used as components of distributed Web-based applications. They commonly interface with existing back-end applications, such as customer relationship management systems, order-processing systems, and so on.
A Web Service module is a virtual module that includes both a Web Application and a Web Service deployment descriptor at minimum. A Web Service module may also include EJBs that implement the Web Service.
Deployable Applications
J2EE also defines several different types of deployable applications: Web Applications, Enterprise Applications, and client applications. Applications generally include one or more standalone J2EE modules to provide a logical service, and may also provide a direct user interface to the applications' contents.
Web Application
A Web Application always includes the following files:
- A servlet or JSP page, along with any helper classes.
- A web.xml deployment descriptor, a J2EE standard XML document that configures the contents of a WAR file.
Web Applications may also contain JSP tag libraries, static .html and image files, supporting classes and .jar files, and a weblogic.xml deployment descriptor, which configures WebLogic Server-specific elements for Web Applications.
Enterprise Application
An Enterprise Application consists of one or more of the following J2EE applications or modules:
- Web Applications
- Enterprise Java Beans (EJB) modules
- Resource Adapter modules
An Enterprise Application is packaged as a JAR file with an .ear extension, but is generally deployed as an exploded EAR directory. An exploded EAR directory contains all of the JAR, WAR, and RAR modules (also in exploded format) for an application as well as the XML descriptor files for the Enterprise Application and its bundled applications and modules.
Client Application Archives
The J2EE specification provides the ability to include a client application archive file within an Enterprise Application. A J2EE client application module contains the Java classes that execute in the client JVM (Java Virtual Machine) and deployment descriptors that describe EJBs (Enterprise JavaBeans) and other WebLogic Server resources used by the client. This enables both the server-side and client-side components to be distributed as a single unit. Client modules in an EAR are defined using the J2EE standard application-client.xml deployment descriptor and an optional WebLogic Server descriptor, client-application.runtime.xml.
Startup and Shutdown Classes
Startup and shutdown classes can be configured to load and execute when you start up or gracefully shut down a server. The deployment process for startup and shutdown classes differs from other deployable units, because you do not specify any actual deployment files. Instead, you identify the servers that will execute the class, and specify the classpath and optional arguments to use for execution.
XML Deployment Descriptors for Deployment Units
A key file that defines each type of deployment unit is its XML deployment descriptor. The deployment descriptor is an XML document that defines certain runtime characteristics for the application or module. By editing the XML deployment descriptor, you modify runtime behavior for the deployment unit without having to recompile code or rebuild the deployment unit itself; the new behavior is read from the descriptor file and implemented when you deploy the application or module.
For example, the WebLogic deployment descriptors for an EJB allow you to specify the number of beans to keep in the cache when you deploy the EJB to a server. If you need to change the number of cached beans for performance reasons, you simply change the deployment descriptor.
J2EE defines the organization and content of required XML deployment descriptors for each deployment unit. In addition, you can specify optional WebLogic Server XML deployment descriptors to configure WebLogic-specific behavior for handling the deployment. WebLogic Server deployment descriptors enable you to maintain the portability of the original J2EE module while utilizing features only available in WebLogic Server.
You create deployment descriptors manually, or generate them with WebLogic Server Java-based utilities. When you receive a J2EE-compliant JAR file from a developer, it should already contain the J2EE-defined and WebLogic Server deployment descriptors. The Administration Console also enables you to modify key deployment descriptor elements of a deployed application, which can help you tune the application's run-time behavior and performance.
Deployment Files
WebLogic Server allows you to store deployment units either as a single archive file, or as an exploded directory that contains the same contents of the archive file.
Archive Files
In most production environments, you receive a deployment unit as an archive file. An archive file is a single file that contains all of an application's or module's classes, static files, directories, and deployment descriptor files. Archive files are typically created by using the jar utility or Ant's jar tool.
Deployment units that are packaged using the jar utility have a specific file extension depending on the type:
- EJBs are packaged as .jar files.
- Web Applications are packaged as .war files.
- Resource Adapters are packaged as .rar files.
- Enterprise Applications are packaged as .ear files, and can contain any combination of EJBs, Web Applications, and Resource Adapters.
- Web Services can be packaged either as .ear files or as .war files.
Note: Startup and shutdown classes are not packaged - you simply specify the classpath to use when assigning target servers.
Although you can deploy an archive file directly to WebLogic Server, deploying Exploded Archive Directories provides some additional redeployment capabilities.
Exploded Archive Directories
An exploded archive directory contains the same files and directories as a jar archive. However, the files and directories reside directly in your file system and are not packaged into a single archive file with the jar utility.
A deployment unit should be deployed as an exploded archive directory, rather than a single archive file, in the following circumstances:
- You want to perform partial updates to a deployed application without redeploying the entire application.
- You want to use the Administration Console to dynamically edit and persist selected deployment descriptor values for the deployment. (You cannot edit deployment descriptor values in the console for deployments from archive files.)
- You are deploying a Web Application that performs direct file system I/O through the application context (for example, a Web Application that tries to dynamically edit or update parts of the Web Application itself). In this case, the modules that perform the I/O operations should have a physical filesystem directory in which to work; you cannot obtain a file when the application is deployed as an archive, as per the specification.
- You are deploying a Web Application or Enterprise Application that contains static files that you will periodically update. In this case, it is more convenient to deploy the application as an exploded directory, because you can update and refresh the static files without re-creating the archive.
Unpacking an Archive File
If you have an archive file that you want to deploy as an exploded archive directory, use the jar utility to unpack the archive file in a dedicated directory. For example:
mkdir /myapp
cd /myapp
jar xvf /dist/myapp.ear
If you are unpacking an archive file that contains other module archive files (for example, an Enterprise Application or Web Service that includes JAR or WAR files) and you want to perform partial updates of those modules, expand the embedded archive files as well. Make sure that you unpack each module into a subdirectory having the same name as the archive file. For example, unpack a module named myejb.jar into a /myejb.jar subdirectory of the exploded Enterprise Application directory.
Note: If you want to use different subdirectory names for the archived modules in an exploded EAR file, modify any references to those modules in the application itself. For example, update the URI values specified in application.xml and CLASSPATH entries in the manifest.mf file.
Location of Files
To deploy a new archive or exploded archive directory, the file(s) must be accessible by the Administration Server for your domain. This means they must reside on the Administration Server machine, or they must be available via a remote, network-mounted directory.
When using the Administration Console to deploy a module for the first time, you have the option to upload files to the Administration Server machine if they are not otherwise available.
Best Practices for Deployment
BEA recommends the following best practices when deploying applications:
- Package deployment files in an archive format (.ear, .jar, .war, and so forth) when distributing files to different users or environments.
- Check the scenarios described under Exploded Archive Directories before deploying. In many cases it is more convenient to deploy applications in exploded format rather than archive format.
- The Administration Console, weblogic.Deployer tool, and wldeploy Ant task all provide similar functionality for deploying applications:
- Use the Administration Console for interactive deployment sessions where you do not know the exact location of deployment files, or the exact names of target servers or deployed applications.
- Use weblogic.Deployer to integrate deployment commands with existing administrative shell scripts or automated batch processes.
- Use wldeploy in conjunction with the split development directory for developing and deploying new applications. wldeploy can also be used in place of weblogic.Deployer in administration environments that use Ant, rather than shell scripts.
- Use wldeploy, rather than the applications directory, to deploy your own applications during development. The applications directory is best used for quickly running new applications in a test or temporary. For example, if you download a sample application and want to evaluate its functionality, the applications directory provides a quick way to deploy the application into a development server.
Security Roles Required for Deployment
The built-in security roles for "Admin" and "Deployer" users allow you to perform deployment tasks using the WebLogic Server Administration Console.
|
|
|