Enterprise Applications

(1)

1

.

Enterprise Applications

At the end of this module you will be able to:

9 Describe the differences between EJB types

9 Deploy EJBs

9 Define an Enterprise Application

9 Dxplain the directory structure of an Enterprise

Application

9 Work with Enterprise Applications

Module 11

Enterprise Applications-1

Module 11

Enterprise Applications-1

(2)

Road Map

1. EJB Applications

–

Major EJB Types and Their Purpose

2. Enterprise Applications

(3)

3

.

Enterprise JavaBeans™

f

Enterprise JavaBeans

™ (EJB) standardizes

development and deployment of Java server

components.

f

The EJB specification defines relationships between:

–

the EJB and its container

–

the container and the application server

–

the container and the client

Enterprise Applications-3 Enterprise Applications-3

(4)

Types of EJBs

fStore logging messages

fAsynchronous & stateless

fConsume JMS messages Message Driven fRepresent a player’s statistics fRepresent a stock’s history

fRepresent persisted data

fCan survive a crash

fAre synchronous Entity

fBook a flight & car rental for travel

fManage a shopping cart

fConversational interaction

fMaintain state for client

fAre synchronous

fDo not survive crashes Stateful

Session

fCheck validity of stock symbol

fCalculate billing of a phone call

fDo not maintain state

fAre synchronous

fDo not survive crashes

fAre maintained in memory Stateless Session Example Description EJB Type Enterprise Applications-4 Enterprise Applications-4

Each of the EJBs has a particular design approach and requirements for its construction. There are many benefits that result from having a variety of EJB types. The differences in EJB types allow an application server to optimize performance by being able to make assumptions about the state and persistence level of the component. The EJBs that have no state management can have a higher degree of pooling than EJBs that have state. There are three levels of state behavior that a component can assume: no state, not persisted, persisted

Stateless session EJBs are components that implement a single-use service. That service can be invoked many times, but since the component does not maintain any state, the resulting effect is that the invocation provided a single use. In a lot of ways, session beans provide a “reusable single-use service.”

Stateful session beans are very similar to their stateless session bean counterparts. In fact, stateful session beans and stateless session beans are implemented in exactly the same manner. So, what is different about them? Stateful session beans are designed to maintain state across multiple client invocations on behalf of the client. The stateful session bean does this by storing stateful properties in the attributes of the

component itself. An EJB container is then responsible for ensuring that subsequent client invocations for the same stateful bean are routed back to the object that hosts the stateful attributes.

(5)

5

.

EJB Application Directory Structure

f

EJB components come

packaged in JAR files.

f

EJBs are configured by

modifying deployment

descriptors.

EJB App JAR Format:

EJB are deployed in the form of a JAR archive file. As with Web applications, EJB applications must follow a specific structure and contains XML deployment descriptors. Here’s an overview of the various files and folders involved:

• The staging directory: The staging directory is somewhere where the JAR file image is being built.

This folder does not end up inside the JAR file, but instead its contents end up as the root of the JAR file.

• Class files for the EJBs. The root of the JAR file contains class files and folders that form the packages for these EJBs.

• META-INF: This folder contains the deployment descriptors and the utility classes and libraries:

ejb-jar.xml

: standard deployment descriptor

weblogic-ejb-jar.xml

: WebLogic-specific deployment descriptor

weblogic-cmp-rdbms-jar.xml

: WebLogic-specific deployment

descriptor used for object-to-relational mapping of CMP Entity EJBs.

classes

folder: contains the class files for utility objects, and the folders that

form the packages of these classes.

(6)

EJB Administrator Tasks with WLS

f

EJB administrator tasks include:

–

configure and deploy

–

resolve JNDI and other infrastructure issues

–

monitor EJB caches and pools

So the different tasks that administrator should be aware of are: 1. Setting up stateless session EJBs’ pool size.

2. Setting up stateful session EJBs’ cache size and related information. 3. Setting up entity EJBs’ pool and cache size, and related information.

(7)

7

.

EJB Deployment

f

Use the same methods as for Web Application

deployment:

–

auto-deployment

–

console deployment

–

command-line deployment

Deployment of an EJB is similar to deployment of Resource Adaptors, Web applications, and Enterprise Applications.

Like these deployment units, you can deploy an EJB in an exploded directory format or as an archive file. To view all the deployed EJB Applications OR to deploy a new EJB Application, Select Deployment >

(8)

EJB Redeployment Considerations

f

To update EJB Applications from the console:

f

Note that:

–

only implementation classes can be updated

–

interfaces cannot be updated

1

2

Once an EJB has been successfully deployed, if you make a change to the deployed EJB, you must redeploy the EJB for the changes to take effect.

From the WebLogic Server Administration Console update EJB as follows: 1. Choose EJB from the Deployments node in the left pane of the Console. .

2. Choose the Deploy tab from the dialog in the right pane and update the EJB by clicking the Redeploy b.

You can update only the EJB implementation class, not the public interfaces or public support classes. If you change the contents of a compiled ejb.jar file in applications (by repackaging, recompiling, or copying over the existing ejb.jar), WebLogic Server automatically attempts to redeploy the ejb.jar file using the automatic deployment feature.

Note: Because the automatic redeployment feature uses dynamic deployment, WebLogic Server can only redeploy an EJB’s implementation classes. You cannot redeploy an EJB’s public interfaces

Should you ever modify an uncompiled ejbc .jar in the applications directory (either by repackaging or copying over the JAR file), WebLogic Server automatically recompiles and redeploys the JAR using the same steps.

Note: Because the automatic redeployment feature uses dynamic deployment, WebLogic Server can only redeploy an EJB’s implementation classes. You cannot redeploy an EJB’s public interfaces.

(9)

9

.

Monitoring EJB Applications

(10)

… Monitoring EJBs

To Monitor a specific EJB Application, select the EJB Application >Monitoring.

(11)

11

.

Section Review

9 EJB applications

9 Major types of Enterprise JavaBeans (EJBs)

9 EJB application configuration

In this section we discussed:

(12)

Road Map

1. EJB Applications

2. Enterprise Applications

–

Enterprise Application Concepts

–

Enterprise Archive (.ear) File Structure

–

Enterprise Application Configuration

–

Enterprise Application Deployment

(13)

13

.

What Is an Enterprise Application?

f

An enterprise application is a grouping of several

resources into one deployable unit packaged in an

.ear

file.

f

These resources include:

–

Web applications (

.war

)

–

EJB applications (

.jar

)

–

Java applications (

.jar

)

–

Resource adapters (

.rar

)

(14)

Why Enterprise Applications?

f

Use enterprise applications to:

–

avoid name space clashes

–

declare Enterprise-wide security roles

–

deploy an application as one unit

–

share Enterprise-wide EJB resources

–

configure local JDBC pools

–

configure local XML resources

(15)

15

.

EAR File Structure

f

An example directory structure of an enterprise

applicationtton is shown below:

Another Web Application module Another Java module

Another EJB module

Document root of enterprise application META-INF directory

WLS Enterprise application deployment descriptor

Description Directory / File

Enterprise application deployment descriptor An EJB module

A Java module

A Web Application module

(16)

Configuring WLS Specific Features

f

Configure Enterprise-wide WLS specific features with

weblogic-application.xml

deployment

descriptor:

–

XML parsers

–

XML entity mappings

–

JDBC connection pools

–

security realms

Application scoping refers to configuring resources for a particular enterprise application rather than for an entire WebLogic Server configuration. In the case of XML, these resources include parser, transformer, external entity, and external entity cache configuration. The main advantage of application scoping is that it isolates the resources for a given application to the application itself. Using application scoping, you can configure different parsers for different applications, store the DTDs for an application within the EAR file or exploded enterprise directory, and so on.

Another advantage of using application scoping is that by associating the resources with the EAR file, you can run this EAR file on another instance of WebLogic Server without having to configure the resources for that server.

To configure XML resources for a particular application, you add information to the weblogic-application.xmldeployment descriptor file located in the META-INFdirectory of the EAR file or exploded enterprise application directory.

For more information see:

(17)

17

.

Deploying EJBs and Enterprise

Applications

f

Use the same methods as for Web Application

deployment:

–

auto-deployment

–

console deployment

–

command-line deployment

f

Applications and EJBs can be deployed:

–

in an archived file (.ear, .jar)

–

or in exploded (open) directory format

(18)

Deploying Enterprise Applications

f

Enterprise Applications are administered as a unit:

–

WLS separates Web and EJB modules (.war, .jar) into

deployment units

–

modules can be individually deployed, redeployed and

undeployed

–

modules can be individually configured and monitored

1 2

3

4

(19)

19

.

Result of Enterprise Deployment

(20)

Redeployment and Classloaders…

f

Classloaders:

– allow Java applications to add Java classes to an already executing Java process

– enable WLS to host several applications in the same JVM

– ensure that classes of one application do not clash with those of another application

– are created for each EJB, Web, or Enterprise Application

f

When a deployed EJB application is updated:

– classes for the EJB application are marked as unavailable in the server

– the EJB's classloader and associated classes are removed

– a new EJB classloader is created which loads and maintains the revised EJB classes

Changing Classes in a Running Program:

WebLogic Server allows application components such as EJBs to be changed to a newer version while the server is running. This process is known as hot-deploy or hot-redeploy and is closely related to

classloading.

Java classloaders do not have any standard mechanism to undeploy or unload a set of classes. Rather, an application-specific classloader is created as a child of the classpath classloader. When a new version of the application is deployed, a new application classloader is created. This scheme works as long as the application classes are being loaded by the new classloader. If a class is in the system classpath, it cannot be changed while the server is running.

Application Classloader Hierarchy:

WebLogic Server automatically creates a set of classloaders when an application is deployed. The base application classloader loads any EJB JAR files in the application. A child classloader is created for each Web Application WAR file.

Because it is common for Web Applications to call EJBs, the WebLogic Server application classloader architecture allows JavaServer Page (JSP) files and servlets to see the EJB interfaces in their parent classloader. This architecture also allows Web Applications to be redeployed without redeploying the EJB tier. In practice, it is more common to change JSP files and servlets than to change the EJB tier.

(21)

21

.

EAR Class Libraries

f

Extending the J2EE spec, 8.1 has added

APP-INF/lib

and

APP-INF/classes

to the standard J2EE ear file.

f

When the app is initialized, paths extracted are

appended to the beginning of the app’s $CLASSPATH

f

Classes are added to the root classloader of the

application.

(22)

Resource Connector Deployments

f

WebLogic Server also support the .RAR standard for

the deployment of J2CA compliant adapters.

–

Inside WebLogic .RAR files are deployed as ‘Resource

Connectors’

–

RAR files contain all of the necessary information to deploy a

J2CA adapter

–

RAR files are deployed in the same manner as a EAR or WAR

file

–

Once the RAR files has been deployed it can be configured as

a pool, just like a JDBC Connection Pool.

(23)

23

.

Resource Connector Deployments

(24)

Section Review

9 The structure of Enterprise Applications

9 Deploying Enterprise Applications

In this section we discussed:

(25)

25

.

Exercise

f

In this lab you will deploy Enterprise JavaBeans.

f

Ask the instructor for any clarification.

f

The instructor will determine the stop time.

ENTA 18—Deploying Enterprise JavaBeans

Lab Exercise

(26)

Exercise

f

In this lab you will configure resources used by an

Enterprise Application and then deploy the Enterprise

Application.

f

Ask the instructor for any clarification.

f

The instructor will

determine the stop time.

ENTA 19—Deploying an Enterprise Application

Lab Exercise

(27)

27