|
|
|
|
|
|
| | | |
Developing WebLogic Server J2EE Applications
The following sections describe how to create different types of WebLogic Server J2EE applications (such as enterprise applications, Web applications, and Enterprise JavaBeans) and set up a development environment:
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 Web Applications: Main Steps
Creating a Web application requires creating HTML pages, JSPs, servlets, JSP taglibs, and two deployment descriptors, and then packaging everything into a *.war file. The *.war file is deployed on WebLogic Server as a Web application.
Here are the main steps for creating a Web application:
For detailed information about creating JSPs, refer to Programming WebLogic JSP.
For detailed information about creating servlets, refer to Programming WebLogic HTTP Servlets.
For detailed information about compiling, refer to Preparing to Compile.
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.
You can create the web.xml and weblogic.xml deployment descriptors by hand, or you can use a Java-based utility included in WebLogic Server to automatically generate them. For more information on automatically generating these files, see Automatically Generating Deployment Descriptors.
See Assembling and Configuring Web Applications for detailed information on the elements in these deployment descriptors and instructions for creating them by hand.
The first step in creating a *.war file is to create a Web application staging directory. JSP pages, HTML pages, and multimedia files referenced by the pages are saved in the top level of the 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. When the Web application components are all in place in the staging directory, you create the *.war file with the JAR command.
For detailed information about creating a *.war file, refer to Packaging Web Applications.
While you are testing the Web application you might need to edit the web.xml and weblogic.xml deployment descriptors; you can do this manually, or you can use the deployment descriptor editor in the Administration Console. For detailed information on using the deployment descriptor editor, see Editing Deployment Descriptors.
Refer to BEA WebLogic Server Administration Guide for detailed information about auto-deploying components and applications.
Refer to BEA WebLogic Server Administration Guide for detailed information about deploying components and applications.
Creating Enterprise JavaBeans: Main Steps
Creating an Enterprise JavaBean requires creating the classes for the particular EJB (session, entity, or message-driven) and the EJB-specific deployment descriptors, and then packaging everything up into an *.ear file to be deployed on WebLogic Server.
Here are the main steps for creating an Enterprise JavaBean:
Message-driven beans, however, require only an implementation class.
For detailed information about compiling, refer to Preparing to Compile.
You can create the EJB deployment descriptors by hand, or you can use a Java-based utility included in WebLogic Server to automatically generate them. For more information on automatically generating these files, see Automatically Generating Deployment Descriptors.
For detailed information about the elements in the EJB-specific deployment descriptors and how to create the files by hand, refer to Programming WebLogic Enterprise JavaBeans.
The first step in creating a *.jar file is to create an EJB staging directory. Place the compiled Java classes in the staging directory and the deployment descriptors in a subdirectory called META-INF. Then 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 *
For detailed information about creating the EJB *.jar archive file, refer to Packaging Enterprise JavaBeans.
While you are testing the EJB you might need to edit the EJB deployment descriptors; you can do this manually, or you can use the deployment descriptor editor in the Administration Console. For detailed information on using the deployment descriptor editor, see Editing Deployment Descriptors.
Refer to BEA WebLogic Server Administration Guide for detailed information about auto-deploying components and applications.
Refer to BEA WebLogic Server Administration Guide for detailed information about deploying components and applications.
Creating WebLogic Server Enterprise Applications: Main Steps
Creating a WebLogic Server enterprise 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 for creating a WebLogic Server enterprise application:
Programmers create servlets and EJBs using the J2EE APIs for these components. Web designers create Web pages using HTML/XML, and JavaServer Pages.
For overview information about creating Web and EJB components, refer to Creating Web Applications: Main Steps and Creating Enterprise JavaBeans: Main Steps.
For detailed information about creating the Java code that makes up the Web and EJB components, refer to Programming WebLogic Enterprise JavaBeans, Programming WebLogic HTTP Servlets, and Programming WebLogic JSP.
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 supplement the J2EE-specified descriptors with information required to deploy components in WebLogic Server.
You can create the these deployment descriptors by hand, or you can use a Java-based utility included in WebLogic Server to automatically generate them. For more information on automatically generating these files, see Automatically Generating Deployment Descriptors.
Refer to Assembling and Configuring Web Applications for detailed information about writing Web component deployment descriptors by hand and to Programming WebLogic Enterprise JavaBeans for detailed information about writing EJB component deployment descriptors by hand.
Component archives are JAR files containing all of the component files, including deployment descriptors. You package Web components into a *.war file and EJB components into an EJB *.jar file.
Refer to Packaging Web Applications and Packaging Enterprise JavaBeans for detailed information for creating component archives.
The enterprise application deployment descriptor, application.xml, lists individual components that are assembled together in an application.
You can create the application.xml deployment descriptor by hand, or you can use a Java-based utility included in WebLogic Server to automatically generate it. For more information on automatically generating this file, see Automatically Generating Deployment Descriptors.
Refer to application.xml Deployment Descriptor Elements for detailed information about the elements of the application.xml file.
Package the Web and EJB component archives along with the enterprise application deployment descriptor into an enterprise archive (*.ear) 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 EAR file.
For detailed information about creating the Enterprise Application *.ear archive file, refer to Packaging Enterprise Applications.
While you are testing the enterprise application you might need to edit the application.xml deployment descriptor; you can do this manually, or you can use the deployment descriptor editor in the Administration Console. For detailed information on using the deployment descriptor editor, see Editing Deployment Descriptors.
Refer to BEA WebLogic Server Administration Guide for detailed information about auto-deploying components and applications.
Refer to BEA WebLogic Server Administration Guide for detailed information about deploying components and applications.
Figure 2-1 illustrates the process for developing and packaging WebLogic Server enterprise applications.
Figure 2-1 Creating Enterprise Applications
Creating Resource Adapters: Main Steps
Creating a resource adapter requires creating the classes for a resource adapter and the connector-specific deployment descriptors, and then packaging everything up into an .rar file to be deployed on WebLogic Server.
Creating a New Resource Adapter (.rar)
The following are the main steps for creating a resource adapter (.rar):
When implementing a resource adapter, you must specify classes in the ra.xml file. For example:
The first step in creating a .jar file is to create a connector staging directory. Place the .jar file in the staging directory and the deployment descriptors in a subdirectory called META-INF.
Then you create the resource adapter archive by executing a jar command like the following in the staging directory:
jar cvf myRAR.rar *
For detailed information about creating the resource adapter .jar archive file, refer to Packaging Resource Adapters.
For detailed information about creating connector-specific deployment descriptors, refer to Programming the WebLogic J2EE Connector Architecture.
jar cvf myRAR.rar *
For detailed information about creating the resource adapter archive file, refer to Packaging Resource Adapters.
While you are testing the resource adapter you might need to edit the deployment descriptors; you can do this manually, or you can use the deployment descriptor editor in the Administration Console. For detailed information on using the deployment descriptor editor, see Editing Deployment Descriptors.
Refer to BEA WebLogic Server Administration Guide for detailed information about auto-deploying components and applications.
Refer to BEA WebLogic Server Administration Guide for detailed information about deploying components and applications.
Modifying an Existing Resource Adapter (.rar)
The following is an example of how to take an existing resource adapter (.rar) and modify it for deployment to WebLogic Server. This involves adding the weblogic-ra.xml deployment descriptor and repacking.
mkdir c:/stagedir
cp blackbox-notx.rar c:/stagedir
cd c:/stagedir
jar xf blackbox-notx.rar
The staging directory should now contain the following:
Execute these commands to see these files:
c:/stagedir> ls
blackbox-notx.jar
META-INF
c:/stagedir> ls META-INF
Manifest.mf
ra.xml
Refer to Programming the WebLogic J2EE Connector Architecture for more information on the weblogic-ra.xml DTD.
cp weblogic-ra.xml c:/stagedir/META-INF
c:/stagedir> ls META-INF
Manifest.mf
ra.xml
weblogic-ra.xml
jar cvf blackbox-notx.jar -C c:/stagedir
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.
This section reviews the software required to develop WebLogic Server applications and describes optional tools for development and debugging.
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.
You use an XML editor to edit the XML files used by WebLogic Server, such as the EJB and Web application deployment descriptors, the config.xml file, and so on. WebLogic Server includes the following two XML editors:
For detailed information about using these XML editors, see Editing Deployment Descriptors.
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 you debug 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 target JVM before deploying.
Never deploy untested code on a WebLogic Server that is serving production applications. This means that 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. Connection pools are a collection of ready-to-use database connections. When a connection pool starts up, it creates a specified number of identical physical database connections. By establishing connections at start-up, the connection pool eliminates the overhead of creating a database connection for each application. BEA recommends that both client and server-side applications obtain connections from a connection pool through a Data Source on the JNDI tree. When finished with a connection, applications return the connection to the connection pool.
Multipools are multiplexers for basic connection pools. To the application they appear exactly as basic pools, but multipools allow you to establish a pool of connection pools, in which the connection attributes vary from connection pool to connection pool. All of the connections in a given connection pool are identical, but the connections in each connection pool in a multipool should vary in some significant way such that an expected failure of one pool will not invalidate another pool in the multipool. Usually these pools will be to different instances of the same database.
Multipools are only useful if there are multiple distinct database instances that can equally handle an application connection, and the application system takes care of synchronizing the databases when application work is distributed among the databases. In rare cases it may be valuable to have the pools to the same database instance, but as different users. This would be useful if the DBA disabled one user, leaving the other user viable.
By default, a clustered multipool provides high availability (DBMS failover). A multipool can be optionally configured to also provide load balancing.
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.
You can use third-party software products, such as WebGain Studio, WebGain StructureBuilder, and BEA WebLogic Integration Kit for VisualAge for Java, to enhance your WebLogic Server development environment.
For more information, see the BEA WebLogic Developer Tools Resources Web page which provides developer tools information for products that support the BEA application servers.
To download some of these tools, see the BEA WebLogic Server Downloads Web page.
Note: Check with the software vendor to verify software compatibility with your platform and WebLogic Server version.
Compiling Java programs for WebLogic Server is the same as compiling any other Java program. To compile successfully, you must:
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 through 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:
For more information on the version of J2EE (1.2 or 1.3) that your WebLogic Server instance implements, see J2EE Platform.
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:
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.
Editing Deployment Descriptors
You can edit the deployment descriptors of WebLogic applications and components using one of the following tools:
Use either editor to update existing elements in, add new elements to, and delete existing elements from the following deployment descriptors:
To edit XML files, use the BEA XML Editor, an entirely Java-based XML stand-alone editor. It is a simple, user-friendly tool for creating and editing XML files. It displays XML file contents both as a hierarchical XML tree structure and as raw XML code. This dual presentation of the document provides you with the following two methods of editing the XML document:
BEA XML Editor can validate XML code according to a specified DTD or XML schema.
For detailed information about using the BEA XML Editor, see its on-line help.
You can download BEA XML Editor from the BEA dev2dev.
Using the Administration Console Deployment Descriptor Editor
The Administration Console Deployment Descriptor Editor looks very much like the main Administration Console: the left pane lists the elements of the deployment descriptor files in tree form and the right pane contains the form for updating a particular element.
When you use the editor, you can either update the in-memory deployment descriptor only, or update both the in-memory and disk files. When you click the Apply button after updating a particular element, or the Create button to create a new element, only the deployment descriptor in WebLogic Server's memory is updated; the change has not yet been written to disk. To do this you must explicitly click the Persist button. If you do not explicitly persist the changes to disk, the changes will be lost when you stop and restart WebLogic Server.
Editing EJB Deployment Descriptors
This section describes the procedure for editing the following EJB deployment descriptors using the Administration Console Deployment Descriptor Editor:
For detailed information about the elements in the EJB-specific deployment descriptors, refer to Programming WebLogic Enterprise JavaBeans.
To edit the EJB deployment descriptors, follow these steps:
http://host:port/console
where host refers to the name of the computer upon which WebLogic Server is running and port refers to the port number to which it is listening.
The left pane contains a tree structure that lists all the elements in the three EJB deployment descriptors and the right pane contains a form for the descriptive elements of the ejb-jar.xml file.
Editing Web Application Deployment Descriptors
This section describes the procedure for editing the following Web application deployment descriptors using the Administration Console Deployment Descriptor Editor:
See Assembling and Configuring Web Applications for detailed information on the elements in the Web application deployment descriptors.
To edit the Web application deployment descriptors, follow these steps:
http://host:port/console
where host refers to the name of the computer upon which WebLogic Server is running and port refers to the port number to which it is listening.
The left pane contains a tree structure that lists all the elements in the two Web application deployment descriptors and the right pane contains a form for the descriptive elements of the web.xml file.
Editing Resource Adapter Deployment Descriptors
This section describes the procedure for editing the following resource adapter deployment descriptors using the Administration Console Deployment Descriptor Editor:
For detailed information about the elements in the resource adapter deployment descriptors, refer to Programming the WebLogic J2EE Connector Architecture.
To edit the resource adapter deployment descriptors, follow these steps:
http://host:port/console
where host refers to the name of the computer upon which WebLogic Server is running and port refers to the port number to which it is listening.
The left pane contains a tree structure that lists all the elements in the two resource adapter deployment descriptors and the right pane contains a form for the descriptive elements of the ra.xml file.
Editing Enterprise Application Deployment Descriptors
This section describes the procedure for editing the Enterprise Application deployment descriptor (application.xml) using the Administration Console Deployment Descriptor Editor.
Refer to application.xml Deployment Descriptor Elements for detailed information about the elements of the application.xml file.
Note: The following procedure describes only how to edit the application.xml file; to edit the deployment descriptors in the components that make up the Enterprise application, see Editing EJB Deployment Descriptors, Editing Web Application Deployment Descriptors, or Editing Resource Adapter Deployment Descriptors.
To edit the Enterprise Application deployment descriptor, follow these steps:
http://host:port/console
where host refers to the name of the computer upon which WebLogic Server is running and port refers to the port number to which it is listening.
The left pane contains a tree structure that lists all the elements in the application.xml file and the right pane contains a form for its descriptive elements, such as the display name and icon file names.
|
|
|
|
|
|
Copyright © 2001 BEA Systems, Inc. All rights reserved.
|
