Skip navigation.
Downloads | Product Documentation | Support

Developing WebLogic Server Applications

# Understanding WebLogic Server Applications and Basic Concepts

The following sections provide an overview of WebLogic Server applications and basic concepts.

- J2EE Platform and WebLogic Server
- What Are WebLogic Server J2EE Applications and Modules?
- Web Application Modules
- Enterprise JavaBean Modules
- Connector Modules
- Enterprise Applications
- WebLogic Web Services
- Client Applications
- XML Deployment Descriptors
- Development Software

# J2EE Platform and WebLogic Server

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 multi-tier 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.

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

J2EE defines module behaviors and packaging in a generic, portable way, postponing run-time configuration until the module is actually deployed on an application server.

J2EE includes deployment specifications for Web applications, EJB modules, Enterprise applications, client applications, and connectors. J2EE does not specify how an application is deployed on the target server—only how a standard module or application is packaged.

For each module type, the specifications define the files required and their location in the directory structure.

Note: Because J2EE is backward compatible, you can still run J2EE 1.3 applications on WebLogic Server versions 7.x and later.

Java is platform independent, so you can edit and compile code on any platform, and test your applications on development WebLogic Servers running on other platforms. For example, it is common to develop WebLogic Server applications on a PC running Windows or Linux, regardless of the platform where the application is ultimately deployed.

For more information, refer to the J2EE 1.3 specification at: http://java.sun.com/j2ee/download.html#platformspec

# What Are WebLogic Server J2EE Applications and Modules?

A BEA WebLogic ServerTM J2EE application consists of one of the following modules or applications running on WebLogic Server:

- Web application modules—HTML pages, servlets, JavaServer Pages, and related files. See Web Application Modules.
- Enterprise Java Beans (EJB) modules—entity beans, session beans, and message-driven beans. See Enterprise JavaBean Modules.
- Connector modules—resource adapters. See Connector Modules.
- Enterprise applications—Web application modules, EJB modules, and resource adapters packaged into an application. See Enterprise Applications.

# Web Application Modules

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.
- Optionally, a `weblogic.xml` deployment descriptor, an XML document containing WebLogic Server-specific elements for Web applications.
- A Web application can 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. 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, known as tag libraries, using HTML-like tags. The appc compiler compiles JSPs and translates them into servlets. WebLogic Server automatically compiles JSPs if the servlet class file is not present or is older than the JSP source file. See Using Ant Tasks to Create Compile Scripts.

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.

## More Information on Web Application Modules

See:

- Best Practices for Developing WebLogic Server Applications.
- Split Development Directory Ant Tasks.
- Developing Web Applications for WebLogic Server
- Programming WebLogic Server HTTP Servlets
- Programming WebLogic JSP
- Programming JSP Tag Extensions

# Enterprise JavaBean Modules

Enterprise JavaBeans (EJBs) beans are server-side Java modules that implement a business task or entity and are written according to the EJB specification. There are three types of EJBs: 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.

The container creates an instance of the message-driven bean or it assigns one from a pool to process the message. When the message is received in the JMS Destination, 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.

## EJBs and WebLogic Server

J2EE cleanly separates the development and deployment roles to ensure that modules are portable between EJB servers that support the EJB specification. Deploying an EJB in WebLogic Server requires running the WebLogic Server `appc` compiler to generate classes that enforce the EJB security, transaction, and life cycle policies. See Compiling Java Code.

The J2EE-specified deployment descriptor, `ejb-jar.xml`, describes the enterprise beans packaged in an EJB application. 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 unique to 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 JNDI bind names, clustering, and cache configuration.

For more information on Enterprise JavaBeans, see Programming WebLogic Enterprise JavaBeans.

# Connector Modules

Connectors (also known as resource adapters) contain the Java, and if necessary, the native modules required to interact with an Enterprise Information System (EIS). A resource adapter deployed to the WebLogic Server environment enables J2EE applications to access a remote EIS. WebLogic Server application developers can use HTTP servlets, JavaServer Pages (JSPs), Enterprise Java Beans (EJBs), and other APIs to develop integrated applications that use the EIS data and business logic.

To deploy a resource adapter to WebLogic Server, you must first create and configure WebLogic Server-specific deployment descriptor, weblogic-ra.xml file, and add this to the deployment directory. Resource adapters can be deployed to WebLogic Server as stand-alone modules or as part of an Enterprise application. See Enterprise Applications.

For more information on connectors, see Programming WebLogic J2EE Connectors.

# Enterprise Applications

An Enterprise application consists of one or more Web application modules, EJB modules, and resource adapters. It might also include a client application. An Enterprise application is defined by an application.xml file, which is the standard J2EE deployment descriptor for Enterprise applications. If the application includes WebLogic Server-specific extensions, the application is further defined by a weblogic-application.xml file. Enterprise Applications that include a client module will also have a client-application.xml deployment descriptor and a WebLogic run-time client application deployment descriptor. See Enterprise Application Deployment Descriptor Elements, and Client Application Deployment Descriptor Elements.

For both production and development purposes, BEA recommends that you package and deploy even stand-alone Web applicatons, EJBs, and resource adapters as part of an Enterprise application. Doing so allows you to take advantage of BEA's new split development directory structure, which greatly faciliates application development. See Overview of the Split Development Directory Environment.

An Enterprise application consists of Web application modules, EJB modules, and resource adapters. It can be packaged as follows:

- For development purposes, BEA recommends the WebLogic split development directory structure. Rather than having a single archived EAR file or an exploded EAR directory structure, the split development directory has two parallel directories that separate source files and output files. This directory structure is optimized for development on a single WebLogic Server instance. See Overview of the Split Development Directory Environment. BEA provides the wlpackage Ant task, which allows you to create an EAR without having to use the JAR utility; this is exclusively for the split development directory structure. See Packaging Applications Using wlpackage.
- For development purposes, BEA further recommends that you package stand-alone Web applications and Enterprise JavaBeans (EJBs) as part of an Enterprise application, so that you can take advantage of the split development directory structure. See Organizing J2EE Components in a Split Development Directory.
- For production purposes, BEA recommends the exploded (unarchived) directory format. This format enables you to update files without having to redeploy the application. To update an archived file, you must unarchive the file, update it, then rearchive and redeploy it.
- You can choose to package your application as a JAR archived file using the jar utility with an `.ear` extension. Archived files are easier to distribute and take up less space. An EAR file contains all of the JAR, WAR, and RAR module archive files for an application and an XML descriptor that describes the bundled modules. See Organizing J2EE Components in a Split Development Directory.

The `META-INF/application.xml` deployment descriptor contains an element for each Web application, EJB, and connector module, as well as additional elements to describe security roles and application resources such as databases. See Enterprise Application Deployment Descriptor Elements.

# WebLogic Web Services

Web services can be shared by and used as modules 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 HTTP, thus making them easily accessible by any user on the Web. See Programming WebLogic Web Services.

A Web service consists of the following modules:

- 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 modules, such as Enterprise Java Beans, or with a Java class. They are packaged as standard J2EE Enterprise applications that contain a Web Application (which contains the Web Service deployment descriptor file and the class files for Java class-implemented Web Services) and the EJB JAR file for EJB-implemented Web Services.
- A standard for transmitting 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 for describing 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.
- A standard for clients to invoke Web services (JAX-RPC).
- A standard for finding and registering the Web service (UDDI).

# Client Applications

Java clients that access WebLogic Server application modules range from simple command line utilities that use standard I/O to highly interactive GUI applications built using the Java Swing/AWT classes. Java clients access WebLogic Server modules indirectly through HTTP requests or RMI requests. The modules execute requests in WebLogic Server, not in the client.

In previous versions of WebLogic Server, a Java client required the full WebLogic Server JAR on the client machine. WebLogic Server 8.1 supports a true J2EE application client, referred to as the thin client. A small footprint standard JAR and a JMS JAR—`wlclient.jar` and `wljmsclient.jar` respectively—are provided in the `/server/lib` subdirectory of the WebLogic Server installation directory. Each JAR file is about 400 KB.

A J2EE application client runs on a client machine and can provide a richer user interface than can be provided by a markup language. Application clients directly access Enterprise JavaBeans running in the business tier, and may, as appropriate communicate through HTTP with servlets running in the Web tier. Although a J2EE application client is a Java application, it differs from a stand-alone Java application client because it is a J2EE module, hence it offers the advantages of portability to other J2EE-compliant servers, and can access J2EE services. For more information about the thin client, see Developing a J2EE Application Client (Thin Client) in Programming WebLogic RMI over IIOP.

For more information about all client types supported by WebLogic Server, see Overview of RMI-IIOP Programming Models in Programming WebLogic RMI over IIOP.

# XML Deployment Descriptors

Modules and applications have deployment descriptors—XML documents—that describe the contents of the directory or JAR file. Deployment descriptors are text documents formatted with XML tags. The J2EE specifications define standard, portable deployment descriptors for J2EE modules and applications. BEA defines additional WebLogic-specific deployment descriptors for deploying a module or application in the WebLogic Server environment.

Table 1-1 lists the types of modules and applications and their J2EE-standard and WebLogic-specific deployment descriptors.

Table 1-1 J2EE and WebLogic Deployment Descriptors

Module or Application | Scope | Deployment Descriptors
--- | --- | ---
Web Application | J2EE | `web.xml` See web.xml Deployment Descriptor Elements in Developing Web Applications for WebLogic Server.
WebLogic | `weblogic.xml` See weblogic.xml Deployment Descriptor Elements in Developing Web Applications for WebLogic Server.
Enterprise Bean | J2EE | `ejb-jar.xml` See the Sun Microsystems EJB 2.0 DTD.
WebLogic | `weblogic-ejb-jar.xml` See The weblogic-ejb-jar.xml Deployment Descriptor in Programming WebLogic Enterprise JavaBeans. `weblogic-cmp-rdbms-jar.xml` See The weblogic-cmp-rdbms-jar.xml Deployment Descriptor in Programming WebLogic Enterprise JavaBeans.
Resource Adapter | J2EE | `ra.xml` See the Sun Microsystems Connector 1.0 DTD.
WebLogic | `weblogic-ra.xml` See weblogic-ra.xml Deployment Descriptor Elements in Programming WebLogic Server J2EE Connectors.
Enterprise Application | J2EE | `application.xml` See application.xml Deployment Descriptor Elements.
WebLogic | `weblogic-application.xml` See weblogic-application.xml Deployment Descriptor Elements.
Client Application | J2EE | `application-client.xml` See application-client.xml Deployment Descriptor Elements.
WebLogic | `client-application.runtime.xml` See WebLogic Run-time Client Application Deployment Descriptor.

When you package a module or application, you create a directory to hold the deployment descriptors—`WEB-INF` or `META-INF`—and then create the XML deployment descriptors in that directory. You can use a variety of tools to do this. See Editing Deployment Descriptors.

## Automatically Generating Deployment Descriptors

WebLogic Server provides a variety of tools for automatically generating deployment descriptors. These are discussed in the sections that follow.

### WebLogic Builder

WebLogic Builder is a WebLogic Server tool for generating and editing deployment descriptors for WebLogic Server applications. It can also deploy WebLogic Server applications to single servers. See Deployment Tools Reference in Deploying WebLogic Server Applications.

### EJBGen

EJBGen is an Enterprise JavaBeans 2.0 code generator or command-line tool that uses Javadoc markup to generate EJB deployment descriptor files. You annotate your Bean class file with Javadoc tags and then use EJBGen to generate the Remote and Home classes and the deployment descriptor files for an EJB application, reducing to a single file you need to edit and maintain your EJB .java and descriptor files. See EJBGen Reference in Programming WebLogic Enterprise JavaBeans

### Java-based Command-line Utilities

WebLogic Server includes a set of Java-based command-line utilities that automatically generate both standard J2EE and WebLogic-specific deployment descriptors for Web applications and Enterprise JavaBeans (version 2.0).

These command-line utilities examine the classes you have assembled in a staging directory and build the appropriate deployment descriptors based on the servlet classes, EJB classes, and so on. These utilities include:

- java weblogic.marathon.ddinit.EarInit—automatically generates the deployment descriptors for Enterprise applications.
- java weblogic.marathon.ddinit.WebInit—automatically generates the deployment descriptors for Web applications.
- java weblogic.marathon.ddinit.EJBInit—automatically generates the deployment descriptors for Enterprise JavaBeans 2.0. If ejb-jar.xml exists, DDInit uses its deployment information to generate weblogic-ejb-jar.xml.

For an example of DDInit, assume that you have created a directory called c:\stage that contains the WEB-INF directory, the JSP files, and other objects that make up a Web application but you have not yet created the web.xml and weblogic.xml deployment descriptors. To automatically generate them, execute the following command:

java weblogic.marathon.ddInit.WebInit c:\stage

The utility generates the web.xml and weblogic.xml deployment descriptors and places them in the WEB-INF directory, which DDInit will create if it does not already exist.

## Editing Deployment Descriptors

BEA offers a variety of tools for editing the deployment descriptors of WebLogic Server applications and modules. Using these tools, you can update existing elements in, add new elements to, and delete existing elements from deployment descriptors. These tools include:

- WebLogic Builder—WebLogic Server tool for generating and editing deployment descriptors for WebLogic Server applications. It can also deploy WebLogic Server applications to single servers. See Deployment Tools Reference in Deploying WebLogic Server Applications.
- XML Editor with DTD validation—Such as BEA XML Editor on dev2dev or XMLSpy. (An evaluation copy of XMLSpy is bundled with this version of WebLogic Server.) See BEA dev2dev Online http://dev2dev.bea.com/index.jsp.
- Administration Console Descriptor tab—This release of WebLogic Server has deprecated the Deployment Descriptor Editor. A new Administration Console Descriptor tab in the has replaced it. Use the Descriptor tab to view, modify, and persist deployment descriptor elements to the descriptor file within WebLogic Server applications in the same manner that they were persisted using the Deployment Descriptor Editor. However, these descriptor element changes take place dynamically at runtime without requiring the resource adapter to be redeployed. The descriptor elements in the Descriptor tab include only those descriptor elements that can be dynamically changed at runtime. See the Administration Console Online Help.

# Development Software

This section reviews required and optional tools for developing WebLogic Server applications.

### Source Code Editor or IDE

You need a text editor to edit Java source files, configuration files, HTML or XML pages, and JavaServer Pages. An editor that gracefully handles Windows and UNIX line-ending differences is preferred, but there are no other special requirements for your editor. You can edit HTML or XML pages and JavaServer Pages with a plain text editor, or use a Web page editor such as DreamWeaver. For XML pages, you can also use BEA XML Editor or XMLSpy (bundled as part of the WebLogic Server package). See BEA dev2dev Online http://dev2dev.bea.com/index.jsp.

### Database System and JDBC Driver

Nearly all WebLogic Server applications require a database system. You can use any DBMS that you can access with a standard JDBC driver, but services such as WebLogic Java Message Service (JMS) require a supported JDBC driver for Oracle, Sybase, Informix, Microsoft SQL Server, IBM DB2, or PointBase. Refer to Platform Support to find out about supported database systems and JDBC drivers.

### Web Browser

Most J2EE applications are designed to be executed by Web browser clients. WebLogic Server supports the HTTP 1.1 specification and is tested with current versions of the Netscape Communicator and Microsoft Internet Explorer browsers.

When you write requirements for your application, note which Web browser versions you will support. In your test plans, include testing plans for each supported version. Be explicit about version numbers and browser configurations. Will your application support Secure Socket Layers (SSL) protocol? Test alternative security settings in the browser so that you can tell your users what choices you support.

If your application uses applets, it is especially important to test browser configurations you want to support because of differences in the JVMs embedded in various browsers. One solution is to require users to install the Java plug-in from Sun so that everyone has the same Java run-time version.

### Third-Party Software

You can use third-party software products to enhance your WebLogic Server development environment. See BEA WebLogic Developer Tools Resources, which provides developer tools information for products that support the BEA application servers.

To download some of these tools, see BEA WebLogic Server Downloads at.

Note: Check with the software vendor to verify software compatibility with your platform and WebLogic Server version.