BEA Logo BEA WebLogic Server Release 6.1

  Corporate Info  |  News  |  Solutions  |  Products  |  Partners  |  Services  |  Events  |  Download  |  How To Buy

   Developing WebLogic Server Applications:   Previous topic   |   Next topic   |   Contents   

 

Understanding WebLogic Server Applications

 

The following sections provide an overview of WebLogic Server applications and application components:

What Are WebLogic Server Application Components?

BEA WebLogic Server applications can include the following components:

Web designers, application developers, and application assemblers create components by using J2EE technologies such as JavaServer Pages, servlets, and Enterprise JavaBeans.

Components are packaged in Java ARchive (JAR) files-archives created with the Java jar utility. JAR files bundle all component files in a directory into a single file, maintaining the directory structure. JAR files include XML descriptors that instruct WebLogic Server how to deploy the components.

Web Applications are packaged in a JAR file with a .war extension. Enterprise beans, WebLogic components, and client applications are packaged in JAR files with .jar extensions.

An Enterprise Application, consisting of assembled components, is a JAR file with an .ear extension. An .ear file contains all of the .jar and .war component archive files for an application and an XML descriptor that describes the bundled components.

To deploy a component or an application, you use the Administration Console or the weblogic.deploy command-line utility to upload JAR files to the target WebLogic Servers.

Client applications (when the client is not a Web browser) are Java classes that connect to WebLogic Server using Remote Method Invocation (RMI). A Java client can access Enterprise JavaBeans, JDBC connections, JMS messaging, and other services by using RMI.

Web Application Components

A Web archive contains all of the files that make up a Web application. A .war file is deployed as a unit on one or more WebLogic Servers. A Web archive can include the following:

Servlets

Servlets are Java classes that execute in WebLogic Server, accept a request from a client, process it, and optionally return a response to the client. A GenericServlet is protocol independent and can be used in J2EE applications to implement services accessed from other Java classes. An HttpServlet extends GenericServlet with support for the HTTP protocol. An HttpServlet is most often used to generate dynamic Web pages in response to Web browser requests.

JavaServer Pages

JSP pages are Web pages coded with an extended HTML that makes it possible to embed Java code in a Web page. JSP pages can call custom Java classes, called taglibs, using HTML-like tags. The WebLogic JSP compiler, weblogic.jspc, translates JSP pages into servlets. WebLogic Server automatically compiles JSP pages if the servlet class file is not present or is older than the JSP source file.

You can also precompile JSP pages and package the servlet class in the Web Archive to avoid compiling in the server. Servlets and JSP pages may depend upon additional helper classes that must also be deployed with the Web application.

Web Application Directory Structure

Web application components are assembled in a directory in order to stage the .war file for the jar command. HTML pages, JSP pages, and the non-Java class files they reference are accessed beginning in the top level of the staging directory.

The XML descriptors, compiled Java classes and JSP taglibs are stored in a WEB-INF subdirectory at the top level of the staging directory. Java classes include servlets, helper classes and, if desired, precompiled JSP pages.

The entire directory, once staged, is bundled into a .war file using the jar command. The .war file can be deployed alone or packaged in an Enterprise Archive (.ear file) with other application components, including other Web Applications, EJB components, and WebLogic components.

For More Information on Web Application Components

For more information about creating Web application components, see these documents:

For help deploying Web Applications, see the following sections of this document:

Enterprise JavaBean Components

Enterprise JavaBeans (EJBs) beans are server-side Java components written according to the EJB specification. There are three types of enterprise beans: session beans, entity beans, and message-driven beans.

EJB Overview

Session beans represent a single client within WebLogic Server. They can be stateful or stateless, but are not persistent; when a client finishes with a session bean, the bean goes away.

Entity beans represent business objects in a data store, usually a relational database system. Persistence-loading and saving data-can be bean-managed or container-managed. More than just an in-memory representation of a data object, entity beans have methods that model the behaviors of the business objects they represent. Entity beans can be shared by multiple clients and they are persistent by definition.

A message-driven bean is an enterprise bean that runs in the EJB container and handles asynchronous messages from a JMS Queue. When a message is received on the JMS Queue, the message-driven bean assigns an instance of itself from a pool to process the message. Message-driven beans are not associated with any client. They simply handle messages as they arrive. A JMS ServerSessionPool provides a similar capability, but without the advantages of running in the EJB container.

Enterprise beans are bundled into a JAR file that contains their compiled classes and XML deployment descriptors.

EJB Interfaces

Entity beans and session beans have remote interfaces, home interfaces, and implementation classes provided by the bean developer. (Message-driven beans do not require home or remote interfaces, because they are not accessible outside of the EJB container.)

The remote interface defines the methods a client can call on an entity bean or session bean. The implementation class is the server-side implementation of the remote interface. The home interface provides methods for creating, destroying, and finding enterprise beans. The client accesses instances of an enterprise bean through the bean's home interface.

EJB home and remote interfaces and implementation classes are portable to any EJB container that implements the EJB specification. An EJB developer can supply a JAR file containing just the compiled EJB interfaces and classes and a deployment descriptor.

EJBs and WebLogic Server

J2EE cleanly separates the development and deployment roles to ensure that components are portable between EJB servers that support the EJB specification. Deploying an enterprise bean in WebLogic Server requires running the WebLogic EJB compiler, weblogic.ejbc, to generate the stub and skeleton classes that allow an enterprise bean to be executed remotely.

WebLogic stubs and skeletons can also contain support for WebLogic clusters, which enable load-balancing and failover for enterprise beans. You can run weblogic.ejbc to generate the stub and skeleton classes and add them to the EJB JAR file, or WebLogic Server can create them by running the compiler at deployment time.

The J2EE-specified deployment descriptor, ejb-jar.xml, describes the enterprise beans packaged in an EJB JAR file. It defines the beans' types, names, and the names of their home and remote interfaces and implementation classes. The ejb-jar.xml deployment descriptor defines security roles for the beans, and transactional behaviors for the beans' methods.

Additional deployment descriptors provide WebLogic-specific deployment information. A weblogic-cmp-rdbms-jar.xml deployment descriptor for container-managed entity beans maps a bean to tables in a database. The weblogic-ejb-jar.xml deployment descriptor supplies additional information specific to the WebLogic Server environment, such as clustering and cache configuration.

For help creating and deploying Enterprise JavaBeans, see Programming WebLogic Enterprise JavaBeans.

WebLogic Components

The WebLogic Server components are startup and shutdown classes, Java classes that execute when deployed or at shutdown time, respectively.

Startup classes can be RMI classes that register themselves in the WebLogic Server naming tree or any other Java class that can be executed in WebLogic Server. Startup classes can be used to implement new services in WebLogic Server. You could create a startup class that provides access to a legacy application or a real-time feed, for example.

Shutdown classes execute when WebLogic Server shuts down and are usually used to free resources obtained by startup classes.

Startup and shutdown classes can be configured in WebLogic Server from the Administration Console. The Java class must be in the server's classpath.

Enterprise Applications

An Enterprise Archive (.ear) file contains the Web archives and EJB archives that constitute a J2EE application. The META-INF/application.xml deployment descriptor contains an entry for each Web and EJB module, and additional entries to describe security roles and application resources such as databases.

You use the Administration Console or the weblogic.deploy command line utility to deploy an .ear file on one or more WebLogic Servers in the domain managed by the Administration Server.

Client Applications

Client-side applications written in Java have access to WebLogic Server services via RMI. Client applications range from simple command line utilities that use standard I/O to highly interactive GUI applications built using the Java Swing/AWT classes.

Client applications use WebLogic Server components indirectly, using HTTP requests or RMI requests. The components actually execute in WebLogic Server, not in the client.

To execute a WebLogic Server Java client, the client computer needs the weblogic_sp.jar file, the weblogic.jar file, the remote interfaces for any RMI classes and enterprise beans on WebLogic Server, and the client application classes.

The application developer packages client-side applications so they can be deployed on client computers. To simplify maintenance and deployment, it is a good idea to package a client-side application in a JAR file that can be added to the client's classpath along with the weblogic.jar and weblogic_sp.jar files.

WebLogic Server also supports J2EE client applications, packaged in a JAR file with a standard XML deployment descriptor. The weblogic.ClientDeployer command line utility is executed on the client computer to run a client application packaged to this specification. See Packaging and Deploying Client Applications for more about J2EE client applications.

 

Back to Top