bea.com | products | dev2dev | support | askBEA

Download Docs | Site Map | Glossary
Search

Developing WebLogic Server Applications

Understanding WebLogic Server J2EE Applications

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

- What Are WebLogic Server J2EE Applications and Components?

- J2EE Platform

- Web Application Components

- Enterprise JavaBean Components

- Connector Component

- Enterprise Applications

- WebLogic Web Services

- Client Applications

- Naming Conventions

What Are WebLogic Server J2EE Applications and Components?

A BEA WebLogic ServerTM J2EE application consists of one of the following components running on WebLogic Server:

- Web components—HTML pages, servlets, JavaServer Pages, and related files

- Enterprise Java Beans (EJB) components—entity beans, session beans, and message-driven beans

- Connector component—resource adapters

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 also 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. Resource adapters are packaged in a JAR file with a .rar extension.

An enterprise application, consisting of assembled Web application components, EJB components, and resource adapters, is a JAR file with an .ear extension. An EAR file contains all of the JAR, WAR, and RAR component archive files for an application and an XML descriptor that describes the bundled components.

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

Client applications that are not Web browsers are Java classes that connect to WebLogic Server using Remote Method Invocation (RMI). A Java client can remotely access Enterprise JavaBeans, JDBC connections, JMS messaging, and other services using access methods such as RMI.

J2EE Platform

WebLogic Server implements Java 2 Platform, Enterprise Edition (J2EE) version 1.3 technologies (http://java.sun.com/j2ee/sdk_1.3/index.html). J2EE is the standard platform for developing multitier enterprise applications based on the Java programming language. The technologies that make up J2EE were developed collaboratively by Sun Microsystems and other software vendors, including BEA Systems.

J2EE applications are based on standardized, modular components. WebLogic Server provides a complete set of services for those components and handles many details of application behavior automatically, without requiring programming.

Note: Because J2EE is backward compatible, you can still run J2EE 1.2 on WebLogic Server 7.0.

Web Application Components

A Web archive (WAR) file has a .war extension and contains the components that make up a Web application. A WAR file is deployed as a unit on one or more WebLogic Servers.

A Web application on WebLogic Server includes the following files:

- At least one servlet or JSP, along with any helper classes.

- A web.xml deployment descriptor, a J2EE standard XML document that describes the contents of a WAR file.

- A weblogic.xml deployment descriptor, an XML document containing WebLogic Server-specific elements for Web applications.

A Web application might also include HTML and XML pages with supporting files such as images and multimedia files.

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

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

You can also precompile JSPs and package the servlet class in a Web archive (WAR) file to avoid compiling in the server. Servlets and JSPs may require additional helper classes that must also be deployed with the Web application.

Web Application Directory Structure

You assemble Web application components in a directory, then package them into a WAR file with the jar command.

HTML pages, JSPs, 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 JSPs.

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

See "Web Applications Directory Structurein Assembling and Configuring Web Applications for detailed information on the Web application directory structure.

For More Information on Web Application Components

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

- Programming WebLogic Server HTTP Servlets

- Programming WebLogic JSP

- Programming JSP Tag Extensions

- Assembling and Configuring Web Applications

Enterprise JavaBean Components

Enterprise JavaBeans (EJBs) beans are server-side Java components that implement a business task or entity and are 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 execute a particular business task on behalf of a single client during a single session. Session beans 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 accessed concurrently 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 in 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 does not run in the EJB container.

Enterprise beans are bundled into a JAR file with a .jar extension 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 classes that enforce the EJB security, transaction, and life cycle policies.

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 EJBs, see Programming WebLogic Enterprise JavaBeans.

Connector Component

The WebLogic Server J2EE Connector architecture enables both Enterprise Information Systems (EIS) vendors and third-party application developers to develop resource adapters that can be deployed in any application server supporting the J2EE 1.3 specification from Sun Microsystems. Resource adapters contain the Java, and if necessary, the native components required to interact with the EIS.

A resource adapter deployed in the WebLogic Server environment enables J2EE applications to access a remote EIS system. Developers of WebLogic Server applications can use HTTP servlets, JavaServer Pages (JSPs), Enterprise Java Beans (EJBs), and other APIs to develop integrated applications that use the data and business logic of the EIS.

As is, the basic Resource ARchive (RAR File) or deployment directory cannot be deployed to WebLogic Server. You must first create and configure WebLogic Server-specific deployment properties in the weblogic-ra.xml file, and add that file to the deployment directory.

To configure and deploy resource adapters, see Programming the J2EE Connector Architecture.

Enterprise Applications

An enterprise J2EE application contains Web and EJB components, deployment descriptors, and archive files. These components are packaged in an Enterprise Archive (EAR) file with an .ear extension.

The META-INF/application.xml deployment descriptor contains an entry for each Web and EJB component, and additional entries to describe security roles and application resources such as databases.

From the WebLogic Administration Server you use the Administration Console or the weblogic.Deployer command line utility to deploy an EAR file on one or more WebLogic Server instances in a domain.

WebLogic Web Services

Web services 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. Web services can reside on different computers and can be implemented by vastly different technologies, but they are packaged and transported using standard Web protocols, such as XML and HTTP, thus making them easily accessible by any user on the Web.

A Web service consists of the following components:

- A Web service implementation hosted by a server on the Web.

  WebLogic Web services are hosted by WebLogic Server. They are implemented using standard J2EE components (such as Enterprise Java Beans) and packaged as standard J2EE Enterprise Applications.

- A standardized way to transmit data and Web service invocation calls between the Web service and the user of the Web service.

  WebLogic Web Services use Simple Object Access Protocol (SOAP) 1.1 as the message format and HTTP as the connection protocol.

- A standard way to describe the Web service to clients so they can invoke it.

  WebLogic Web Services use Web Services Description Language (WSDL) 1.1, an XML-based specification, to describe themselves.

For information on designing, developing, and invoking WebLogic Web services, see Programming WebLogic Web Services.

Client Applications

Client-side applications written in Java that access WebLogic Server components 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 through 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.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.

WebLogic Server also supports J2EE client applications (as opposed to simple Java programs) that are packaged in a JAR file with a standard XML deployment descriptor (client-application.xml) and a WebLogic-specific 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 Client Applications for more about J2EE client applications.

Naming Conventions

WebLogic Server requires you to adhere to the following programmatic naming conventions for WAR, EAR, JAR, and RAR archive files and exploded directories.

- Enterprise JavaBean JAR archived files must end with the .jar extension.

- Resource adapter RAR archived files must end with the .rar extension.

- Web application WAR archived files must end with the .war extension.

- Enterprise application EAR archived files must end with the .ear extension.

- Exploded non-archived versions of all of the above archived files must not end with the .jar, .rar, .war, or .ear extensions respectively.