WebLogic Server Applications
Contents
- 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 J2EE V1.3 technologies. A BEA WebLogic Server J2EE application consists of one or more of the following modules:
Web application HTML pages, servlets, JavaServer Pages, and related files. Enterprise Java Beans entity beans, session beans, and message-driven beans. Connector resource adapters. Enterprise applications Web application modules, EJB modules, and resource adapters packaged into an application.
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 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.
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.
Enterprise JavaBean Modules
Enterprise JavaBeans 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.
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.
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 , Enterprise Java Beans, and other APIs to develop integrated applications that use the EIS data and business logic.
To deploy a resource adapter to WebLogic Server, 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.
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.
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.
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.
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.
- For development purposes, BEA further recommends that you package stand-alone Web applications and Enterprise JavaBeans as part of an Enterprise application, so that you can take advantage of the split development directory structure.
- 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, 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.
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.
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.
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.
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.
| Module or Application | Scope | Deployment Descriptors |
|---|---|---|
| Web Application | J2EE | web.xml |
| WebLogic | weblogic.xml | |
| Enterprise Bean | J2EE | ejb-jar.xml |
| WebLogic | weblogic-ejb-jar.xml | |
| Resource Adapter | J2EE | ra.xml |
| WebLogic | weblogic-ra.xml | |
| Enterprise Application | J2EE | application.xml |
| WebLogic | weblogic-application.xml | |
| Client Application | J2EE | application-client.xml |
| WebLogic | client-application.runtime.xml |
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.
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 used for generating and editing deployment descriptors for WebLogic Server applications. It can also deploy WebLogic Server applications to single servers.
EJBGen
EJBGen is an Enterprise JavaBeans 2.0 code generator 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.
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:
- Generate deployment descriptors for Enterprise applications.
java weblogic.marathon.ddinit.EarInit
- Generate deployment descriptors for Web applications.
java weblogic.marathon.ddinit.WebInit
- Generate deployment descriptors for Enterprise JavaBeans 2.0. If ejb-jar.xml exists, DDInit uses its deployment information to generate weblogic-ejb-jar.xml.
java weblogic.marathon.ddinit.EJBInit
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 the following tools for editing deployment descriptors:
| WebLogic Builder | Edit and generate deployment descriptors for WebLogic Server applications. Can also deploy apps to single servers. |
| 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.) |
| Administration Console Descriptor tab | Dynamically view, modify, and persist deployment descriptor elements in the runtime system without requiring the resource adapter to be redeployed. |
Development Software
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.
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 require a supported JDBC driver for Oracle, Sybase, Informix, Microsoft SQL Server, IBM DB2, or PointBase.
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 tools. Check with the software vendor to verify software compatibility with your platform and WebLogic Server version.
|
|
|