|
|
|
|
|
|
| | | |
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?
A BEA WebLogic ServerTM application is an application composed of one or many J2EE components that runs on WebLogic Server. They can include the following components:
Web designers, application developers, and application assemblers create applications and their components by using J2EE technologies such as JavaServer Pages, servlets, Enterprise JavaBeans, and 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, 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.deploy command-line utility to upload JAR files to the target WebLogic Servers.
Client applications that are not Web browsers are Java classes that connect to WebLogic Server using Remote Method Invocation (RMI). A Java client can access Enterprise JavaBeans, JDBC connections, JMS messaging, and other services by using RMI.
WebLogic Server contains Java 2 Platform, Enterprise Edition (J2EE) technologies. 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.
WebLogic Server 6.1 with J2EE 1.2 and J2EE 1.3 Functionality
BEA WebLogic Server 6.1 is the first e-commerce transaction platform to implement advanced J2EE 1.3 features. To comply with the rules governing J2EE, BEA Systems provides two separate downloads: one with J2EE 1.3 features enabled, and one that is limited to J2EE 1.2 features only. Both downloads offer the same container and differ only in the APIs that are available.
Note: Your CLASSPATH setting for compiling J2EE components depends on whether you want to create components that are completely J2EE 1.2-compliant or components that contain J2EE 1.3 features. For detailed information, see Setting the Classpath for Compiling.
WebLogic Server 6.1 with J2EE 1.2 Plus Additional J2EE 1.3 Features
With this download, WebLogic Server defaults to running with J2EE 1.3 features enabled. These features include EJB 2.0, JSP 1.2, Servlet 2.3, and J2EE Connector Architecture 1.0. When you run WebLogic Server 6.1 with J2EE 1.3 features enabled, J2EE 1.2 applications are still fully supported. The J2EE 1.3 feature implementations use non-final versions of the appropriate API specifications. Therefore, application code developed for BEA WebLogic Server 6.1 that uses the new features of J2EE 1.3 may be incompatible with the J2EE 1.3 platform supported in future releases of BEA WebLogic Server.
WebLogic Server 6.1 with J2EE 1.2 Certification
With this download, WebLogic Server defaults to running with J2EE 1.3 features disabled and is fully compliant with the J2EE 1.2 specification and regulations.
A Web archive contains the files that make up a Web application. A .war file is deployed as a unit on one or more WebLogic Servers.
A Web archive on WebLogic Server always includes the following files:
A Web archive might also include HTML/XML pages with supporting files such as images and multimedia files.
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.
JSP pages are Web pages coded with an extended HTML that makes it possible to embed Java code in a Web page. JSP pages can call custom Java classes, called taglibs, using HTML-like tags. The WebLogic JSP compiler, weblogic.jspc, translates JSP pages into servlets. WebLogic Server automatically compiles JSP pages if the servlet class file is not present or is older than the JSP source file.
You can also precompile JSP pages and package the servlet class in the Web Archive to avoid compiling in the server. Servlets and JSP pages may depend upon additional helper classes that must also be deployed with the Web application.
Web Application Directory Structure
Web application components are assembled in a directory in order to stage the .war file for the jar command. HTML pages, JSP pages, 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 JSP pages.
The entire directory, once staged, is bundled into a .war file using the jar command. The .war file can be deployed alone or packaged in an Enterprise Archive (.ear file) with other application components, including other Web Applications, EJB components, and WebLogic components.
For More Information on Web Application Components
For more information about creating Web application components, see these documents:
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.
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 without the advantages of running in the EJB container.
Enterprise beans are bundled into a JAR file that contains their compiled classes and XML deployment descriptors.
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.
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 the stub and skeleton classes that allow an enterprise bean to be executed remotely.
WebLogic stubs and skeletons can also contain support for WebLogic clusters, which enable load-balancing and failover for enterprise beans. You can run weblogic.ejbc to generate the stub and skeleton classes and add them to the EJB JAR file, or WebLogic Server can create them by running the compiler at deployment time.
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.
The WebLogic Server components are startup and shutdown classes, Java classes that execute when deployed or at shutdown time, respectively.
Startup classes can be RMI classes that register themselves in the WebLogic Server naming tree or any other Java class that can be executed in WebLogic Server. Startup classes can be used to implement new services in WebLogic Server. You could create a startup class that provides access to a legacy application or a real-time feed, for example.
Shutdown classes execute when WebLogic Server shuts down and are usually used to free resources obtained by startup classes.
Startup and shutdown classes can be configured in WebLogic Server from the Administration Console. The Java class must be in the server's CLASSPATH.
The central component within the WebLogic J2EE Connector architecture is the resource adapter, which serves as the "connector." The Connector architecture enables both Enterprise Information Systems (EISs) 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.
When a resource adapter is deployed in the WebLogic Server environment, it enables the development of robust J2EE applications that now have access to 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) 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.
For help configuring and deploying resource adapters, see Programming the WebLogic J2EE Connector Architecture.
An enterprise J2EE application contains both Web and EJB components, deployment descriptors, and archive files. An Enterprise Archive (.ear) file contains the Web archives and EJB archives. 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.deploy command line utility to deploy an .ear file on one or more WebLogic Servers in a domain.
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, using 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, weblogic_sp.jar file (if you are using a Service Pack version of WebLogic Server), 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 and weblogic_sp.jar files.
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 package a client application to this specification. See Packaging Client Applications for more about J2EE client applications.
|
|
|
|
|
|
Copyright © 2001 BEA Systems, Inc. All rights reserved.
|