Developing WebLogic Server Components


	Corporate Info \| News \| Solutions \| Products \| Partners \| Services \| Events \| Download \| How To Buy
	e-docs \| Site Map \| Search \| Contact \| Glossary \| WebLogic Server Documentation

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

The following sections describe how to create WebLogic Server components and set up a development envioronment:

WebLogic Server applications are created by Java programmers, Web designers, and application assemblers. Programmers and designers create components that implement the business logic and presentation logic for the application. Application assemblers assemble the components into applications ready to deploy on WebLogic Server.

Creating WebLogic Server Applications: Main Steps

Creating a WebLogic Server application requires creating Web and EJB components, deployment descriptors, and archive files. The result is an enterprise application archive (.ear file), that can be deployed on WebLogic Server.

Here are the main steps:

Create Web and EJB components for your application.
Programmers create servlets and enterprise beans using the J2EE APIs for these components. Web designers create Web pages using HTML/XML, and JavaServer Pages.
Create deployment descriptors.
Component deployment descriptors are XML documents that provide information needed to deploy the application in WebLogic Server. The J2EE specifications define the contents of some deployment descriptors, such as ejb-jar.xml and web.xml. Additional deployment descriptors provide supplement the J2EE-specified descriptors with information required to deploy components in WebLogic Server.
Create component archive.
Component archives are JAR files containing all of the files that make up the component, including deployment descriptors.
Create application deployment descriptor.
The application deployement descriptor, application.xml, lists individual components that are assembled together in an application.
Assemble application.
Component archives are packaged with the application deployment descriptor in an application JAR file. This is the file that is deployed on WebLogic Server. WebLogic Server uses the application.xml deployment descriptor to locate and deploy the individual components packaged in the JAR file.

Figure 2-1 illustrates the process for developing and assembling WebLogic Server applications.

Figure 2-1 Creating Enterprise Applications

Creating Web Applications: Overview

Web designers create HTML pages and JavaServer Pages to create the Web interface for an application. Java programmers create Servlets and the JSP taglibs referenced in JavaServer Pages (JSPs).

JSP pages, HTML pages, and multimedia files referenced by the pages are saved in the top level of the Web application staging directory. Compiled Servlet classes, taglibs, and, if desired, Servlets compiled from JSP pages are stored under a WEB-INF directory in the staging directory.

Two deployment descriptors are created in the WEB-INF directory: web.xml and weblogic.xml. The web.xml file defines each Servlet and JSP page and enumerates enterprise beans referenced in the Web application. The weblogic.xml file adds additional deployment information for WebLogic Server. See Writing Web Application Deployment Descriptors, for instructions on creating these deployment descriptors.

When the Web application components are all in place in the staging directory, you create the Web archive with a command such as the following, executed in the staging directory:

jar cvf myWebApp.war *

The .war file is ready to be deployed, or it can be added to an Enterprise archive and deployed as part of an application.

Creating Enterprise Beans: Overview

A Java programmer creates an enterprise bean by writing three classes, in accordance with the EJB specification:

An EJB home interface
A remote interface for the bean
An implementation class for the bean

Message-driven beans require only an implementation class. The interfaces and implementation classes are compiled into a staging directory for the bean.

Deployment descriptors are created in a META-INF directory in the top level of the staging directory:

ejb-jar.xml describes the enterprise bean type and its deployment properties using a standard DTD from Sun Microsystems.
weblogic-ejb-jar.xml adds additional WebLogic Server-specific deployment information.
weblogic-cmp-rdbms-jar.xml maps a container-managed entity bean to tables in a database. This file can must have a different name for each CMP bean packaged in a JAR file. The name of the file is specified in the bean's entry in the weblogic-ejb.jar file.

See "Programming WebLogic Enterprise JavaBeans" for help creating EJB deployment descriptors.

After the EJB classes are compiled, you run the weblogic.ejbc EJB compiler to generate the stub and skeleton classes into the staging directory. Then you create the EJB archive by executing a jar command like the following in the staging directory:

jar cvf myEJB.jar *

The EJB .jar file can be deployed as is, or packaged in an Enterprise Archive (.ear) file and deployed with an application.

Creating Enterprise Applications: Overview

When you have assembled all of the Web archives and EJB archives for your application, you can bundle them together in an Enterprise Archive (.ear) file so that you can deploy all of the dependent components together.

Copy the .war and EJB .jar files into a staging directory and then create a META-INF/application.xml deployment descriptor for the application. The application.xml file contains a descriptor for each component in the application, using a DTD supplied by Sun Microsystems.

Create the Enterprise Archive by executing a jar command such as the following in the staging directory:

jar cvf myApp.ear *

Use the Administration Console or the weblogic.deploy command line utility to deploy the application.

Establishing a Development Environment

To develop WebLogic Server applications, you need to assemble your software tools and set up an environment for creating, compiling, deploying, testing, and debugging your code. This section helps you start building your toolkit and setting up the compiler-related environment on your development computer.

Software Tools

This section reviews the software required to develop WebLogic Server applications and describes optional tools for development and debugging.

Source Code Editor or IDE

You need a text editor to edit Java source files, configuration files, HTML/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.

Java Interactive Development Environments (IDEs) such as WebGain VisualCafé usually include a programmer's editor with custom support for Java. An IDE may also have support for creating and deploying Servlets and Enterprise JavaBeans on WebLogic Server, which makes it much easier to develop, test, and debug applications.

You can edit HTML/XML pages and JavaServer Pages with a plain text editor, or use a Web page editor such as DreamWeaver.

Java Compiler

A Java compiler produces Java class files, containing portable byte code, from Java source. The compiler compiles the Java code you write for your applications, as well as the code generated by the WebLogic RMI, EJB, and JSP compilers.

Sun Microsystems Java 2, Standard Edition includes a Java compiler, javac. If you install the bundled JRE when you install WebLogic Server, the javac compiler is installed on your computer.

Other Java compilers are available for various platforms. You can use a different Java compiler for WebLogic Server application development as long as it produces standard Java .class files. Most Java compilers are many times faster than javac, and some are integrated nicely with an IDE.

Occasionally, a compiler generates optimized code that does not behave well in all Java Virtual Machines (JVMs). When debugging problems try disabling optimizations, choosing a different set of optimizations, or compiling with javac to rule out your Java compiler as the cause. Always test your code in each of your target JVMs before deploying.

Development WebLogic Server

Never deploy untested code on a WebLogic Server that is serving production applications, so you will need a development WebLogic Server in your environment. You can run a development WebLogic Server on the same computer you edit and compile on, or you can use one deployed somewhere on the network.

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.

Even if you do not run a development WebLogic Server on your development computer, you must have access to a WebLogic Server distribution to compile your programs. To compile any code using WebLogic or J2EE APIs, the Java compiler needs access to the weblogic.jar file and other JAR files in the distribution directory. Installing WebLogic Server on your development computer makes these files available locally.

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 JMS require a supported JDBC driver for Oracle, Sybase, Informix, Microsoft SQL Server, IBM DB2, or Cloudscape. Refer to the Platform Support Web pageto find out about supported database systems and JDBC drivers.

JDBC connection pools offer such significant performance advantages that you should only rarely consider writing an application that uses a two-tier JDBC driver directly. On a WebLogic cluster, be sure to set up a multipool, which provides load balancing over JDBC connection pools on multiple servers in the cluster.

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 SSL? 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

This section describes several third-party software products that can enhance your WebLogic Server development environment.

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

WebGain VisualCafé Enterprise Edition

VisualCafé Enterprise Edition builds on proven Java development technology and delivers a complete Java Integrated Development Environment (IDE) for the heterogeneous enterprise. Enterprise Edition inherits powerful productivity features and database functionality from the VisualCafé family while introducing unique new server-side development and distributed debugging capabilities to minimize the challenges of enterprise Java application development. VisualCafé Enterprise Edition is the most mature and open Java development environment backed by extensive industry wide support.

Informix Cloudscape

Cloudscape is the first 100% pure Java SQL database management system. Cloudscape is designed to be embedded in client or server applications as a local data manager. It implements SQL-92 with extensions for Java that enable the developer to create a column of type Java class, and to write stored procedures in Java for execution inside the DBMS.

Sybase PowerJ

PowerJ provides a true end-to-end solution for building sophisticated Internet applications, exploiting the benefits of HTML, Java clients, and Java server-side components.

WebGain TopLink

TOPLink for BEA WebLogic is a powerful tool for building EJB applications. TOPLink is seamlessly integrated with BEA WebLogic Server. With TOPLink for BEA WebLogic Server, you can build components for application servers that run on Java, while significantly cutting application development time and expense.

KL Group JProbe

JProbe is a performance-tuning toolkit. With other performance-tuning toolkits, developers working on specific application servers must use command line prompts. Under these circumstances, setting up the session typically involves time-consuming manual configuration, and usually more than a fair share of trial and error. The JProbe 2.5 Server Launch Pad eliminates much of this effort, making server-side tuning fast and easy. JProbe supports many popular Web and application servers, including WebLogic Server.

Versant Enterprise Container

VERSANT Enterprise Container (VEC) is the integration between a VERSANT ODBMS and an EJB-compliant application server. VEC supports WebLogic Server. VERSANT Enterprise Container is an EJB-compliant container that plugs directly into the application server, allowing transparent persistence for your entity beans. VERSANT Enterprise Container is targeted at applications that have complex object models and require high-performance access to persistent data.

eXcelon Javlin

EJB is the standard for building scalable eBusiness applications, from eCommerce, supply-chain, and customer-relationship management, to enterprise information and application portals, and others.

EJB-compliant application servers facilitate the creation, distribution, and integration of eBusiness Java components in the middle tier-but they do not do the same for data. In order to meet or exceed time to market and performance goals, you need a middle-tier data manager like Javlin to complement your EJB server.

Object Design ObjectStore

ObjectStore is an ideal data management solution for developers creating dynamic, reliable, high-performance applications for telecommunications, packaged software, the Internet and other distributed computing environments.

ObjectStore combines best-of-breed, object data management with Java and C++, and ActiveX to enable the development and delivery of high-speed, complex Web transactions, dynamic content, and network management applications.

Preparing to Compile

Compiling Java programs for WebLogic Server is the same as compiling any other Java program. To compile successfully, you must:

Have the Java compiler in your search path
Set your classpath so that the Java compiler can find all of the dependent classes
Specify the output directories for the compiled classes

One way to set up your environment is to create a command file or shell script to set variables in your environment, which you can then pass to the compiler. The setExamplesEnv.cmd (Windows) and setExamplesEnv.sh (UNIX) files in the config/examples directory are examples of this technique.

Putting the Java Tools in Your Search Path

Make sure the operating system can find the compiler and other JDK tools by adding it to the PATH environment variable in your command shell. If you are using the JDK, the tools are in the bin subdirectory of the JDK directory. To use an alternative compiler, such as the sj compiler from WebGain VisualCafé, add the directory containing that compiler to your search path.

For example, if the JDK is installed in /usr/local/java/java130 on your UNIX file system, use a command such as the following to add javac to your path in a Bourne shell or shell script:

PATH=/usr/local/java/java130/bin:$PATH; export PATH

To add the WebGain sj compiler to your path on Windows NT or Windows 2000, use a command such as the following in a command shell or in a command file:

PATH=c:\VisualCafe\bin;%PATH%

If you are using an IDE, see the IDE documentation for help setting up an equivalent search path.

Setting the Classpath for Compiling

Most WebLogic services are based on J2EE standards and are accessed via standard J2EE packages. The Sun, WebLogic, and other Java classes required to compile programs that use WebLogic services are packaged in the weblogic.jar file in the lib directory of your WebLogic Server installation. In addition to weblogic.jar, include the following in your compiler's classpath:

The lib/tools.jar file in the JDK directory, or other standard Java classes required by the Java Development Kit you use.
The weblogic_sp.jar file distributed with a WebLogic Server service pack, if you have one.
This jar file should precede weblogic.jar in your classpath so that the service pack classes are found before any classes they supersede in weblogic.jar.
Classes for third party Java tools or services your programs import.
Other application classes referenced by the programs you are compiling.
Include in your classpath the target directories where the compiler writes the classes you are compiling so that the compiler can locate all of the interdependent classes in your application. The next section has more information on target directories.

Setting Target Directories for Compiled Classes

The Java compiler writes class files in the same directory with the Java source unless you specify an output directory for the compiled classes. If you specify the output directory, the compiler stores the class file in a directory structure that matches the package name. This allows you to compile Java classes into the correct locations in the staging directory you use to package your application. If you do not specify an output directory, you have to move files around before you can create the jar file that contains your packaged component.

J2EE applications consist of modules assembled into an application and deployed on one or more WebLogic Servers or WebLogic Clusters. Each module should have its own staging directory so that it can be compiled, packaged, and deployed independently from other modules. For example, you can package EJBs in a separate module, Web components in a separate module, and other server-side classes in another module.

See the setExamplesEnv scripts in the config/examples directory of the WebLogic Server distribution for an example of setting up target directories for the compiler. The scripts set the following variables:

CLIENT_CLASSES: The directory where compiled client classes are written. These classes are usually standalone Java programs that connect to WebLogic Server. They do not have to be in the WebLogic Server classpath.
SERVER_CLASSES: The directory where server-side classes are written. These classes include startup classes and other Java classes that must be in the WebLogic Server classpath when the server starts up. Application classes should usually not be compiled into this directory, because the classes in this directory cannot be redeployed without restarting WebLogic Server.
EX_WEBAPP_CLASSES: The directory where classes used by the Web Application are written.
APPLICATIONS: The applications directory for the examples domain. Unlike the others, this variable is not used to specify a target for the Java compiler. It is used as a convenient reference to the applications directory in copy commands that move files from source directories into the applications directory. For example, if you have .html, .jsp, and image files in your source tree, you can use the variable in a copy command to install them in your development server.

These environment variables are passed to the compiler in commands such as the following command for Windows:

javac -d %SERVER_CLASSES% *.java

If you do not use an IDE, consider writing a make file, shell script, or command file to compile and package your components and applications. Set the variables in the build script so that you can rebuild components by typing a single command.