programming model issues - ibm...use bean-managed persistence when container-managed persistence...

IBM WebSphere Web Multi-Platform Configuration

Programming Model Issues

08/17/00 © Copyright 2000 IBM Corporation PMI_35.prz 1

What Will be Covered

The topics:EJB TypesEJB ArchitectureEntity Container Managed PersistenceEntity Bean Managed PersistenceTransaction Basics

The topics concluded:Two-Phase CommitEJB Distributed Transaction SupportEJB Portability


EnterpriseJava

Beans

Entity Beans

Session Beans

ContainerManaged

Persistence

BeanManaged

PersistenceStateless Stateful

EJB Types


Every enterprise bean is either an entity bean or a session bean. In fact, EntityBean and SessionBean are interfaces in the EJB API. Your beans will implement one or the other of these interfaces. Both entity and session beans have two subtypes, but these are not different interfaces; instead, they are different ways of "configuring" your enterprise beans.

Client

EJB Server/Container

Home

EJBObject

Bean

Home

EJBObject

Bean Data

EJB Architecture


This shows the logically visible pieces of the EJB architecture. (There are many additional objects involved in the deployed implementation.)

All that you get on the client side are two stubs (proxies) to objects on the server side. These proxies allow the client to communicate with the home and remote interfaces of an enterprise bean. The beans themselves exist only on the server.

On the server side, the EJBHome, a container-provided object representing the home interface, allows you to create and find EJBs. It returns references to EJBObjects, either created or found. The EJBObject, another container-provided object representing the remote interface, handles things like:

Persistence in CMP entity beans Distribution details (CORBA, RMI)Support for transactional behavior

The bean itself, the code you provide, implements only the business methods. The EJB framework handles the rest!

EJB Provider - the programmer/developer

Application Assembler - component integrator - usually the programmer

Deployer - deploys the application on the container

EJB Server and Container Provider - WebSphere Application Server

System Administrator - oversees the deployed application at runtime

EJB Architecture Roles



Entity Container-Managed

Persistence


Information to be obtained for this section:

Transaction aspect chartsNaming and how it pertains to portabilityMapping of CMPHeterogeneous environments and how it pertains to 2PC with Oracle.

Container-managed persistence (CMP) Container is responsible for saving state You specify the container-managed fields Persistence is independent of the data sourceMost portable solution

Entity CMP


NOTE: "Independent of the data source" does not mean that the persistence information is stored in the administrative repository. The statement means that the programmer does not have to worry whether DB2 or Oracle is used to write the beans.

Created and managed at runtime by a container

Can be customized at deployment time

Client access is mediated by EJB container and server

Can be deployed in any compliant EJB container

Can be included in a composite application without changing the source code or recompiling

A client’s view of an enterprise bean is defined by the bean developer

Entity CMP


Component provider can focus on business logic rather than on system programming.

Component provider has a choice of containers that will run their code.

Benefit to the Developer


In order to provide this kind of power, the hierarchical naming structure is used.

The container manages the life cycle of the component.Component instances are pooled for performance reasons.Activation and passivation occurs transparently to the client.

The container can manage database access for the component.

This includes database connection pooling.

Container Responsibilities


Passivation options for advanced:

You can take action so you will know what is happening, but you will not have control. For example, you can set a time-out value that says not to passivate until a specified amount of time has elapsed.

Use the Common Connector Framework in VisualAge for Java to control the number of objects that are accessing a legacy system.

Use the GUI panels for CMP parameters to change the connection pool size.

The EJB 1.1 Specifications outlines three caching options for an entity object's state between transactions.

Option A - Container caches a ready instance between transactions. Container ensures that the instance has exclusive access of the object in persistent storage.Option B - Same as A but the Container does not have exclusive access. It must synchronize the instance's state at the beginning of the transaction.Option C - Container does not cache a "ready" instance between transaction.

WebSphere Advanced Edition 3.02 and beyondUses Option C by defaultUses Option A if the Data Access is set to "exclusive" during entity creation.No plans to add Option B as Option C provides about the same performance but with a cleaner design.

WebSphere Entity Caching Options


NOTE: Option B is not supported.

A finder method is used to find one or more existing entity EJB objects. Each finder method must be named findName, where Name further describes the finder method's purpose. Finders are declared on the EBJHome.At minimum, each home interface must define the findByPrimaryKey method that enables a client to locate an EJB object by using the primary key only. The findByPrimaryKey method has one argument, an object of the bean's primary key class, and returns the type of the bean's remote interface.

Every other finder method must meet the following requirements: It must return the type of the enterprise bean's remote interface or the java.util.Enumeration interface (when a finder method can return more than one EJB object). It must have a throws clause that includes the java.rmi.RemoteException and javax.ejb.FinderException exception classes.

Entity Finders


WebSphere uses lazy evaluation of the enumerations.

This means that the elements in the enumeration are not actually fetched from the DB until you reference them.

This is a major performance win.

But once a transaction is committed, WebSphere is unable to fetch the "un-referenced" portion of the enumeration.

Do all the processing inside the transaction (normal case).Pre-fetch all elements from the enumeration inside the transaction (that is, copy the enumeration).

WebSphere Entity Finders


The entity finders are used to find EJBs, and an entity finder can find an enumeration (a Java structure similar to a sequentially accessed array) of EJBs. However, within WebSphere, each of those EJBs is tied data - essentially a record in a DB.

Lazy evaluation of enumerations means that when WebSphere builds the enumeration, it actually only retrieves only the first five records from the database. WebSphere retrieves more records when you walk through the enumeration past the first five elements.


Entity Bean-Managed

Persistence


Bean-managed persistence (BMP)You write the code to save the bean's state Container does not need to generate DB calls Can exploit existing, more powerful persistence frameworksLess adaptable; persistence is hardcoded

Bean-Managed Persistence


Although beans with bean-managed persistence are less adaptable in theory (that is, less portable across different databases or over different connection protocols), they are currently, for all but the simplest entity bean, less portable across EJB servers from different vendors. This is due, in part, to the fact that many of the underlying standards are still evolving. Bean-managed persistence is also necessary if the container does not support the backend database.

CMP is recommended for Entity bean development. BMP is not recommended because the container support for database connection management is different. WebSphere Enterprise Edition provides JDBC (Java Database Connectivity) 1.0 API (application programming interface) set, while WebSphere Advanced Edition provides the DataSource API from JDBC 2.0.

BMP Entity Beans

BMP is used in entity beans that must map to backend sources that are not supported by a container

Entity beans that use BMPRequire the same pieces as Container-Managed Persistence (CMP) entity beans

Home interfaceRemote interfaceBean class (this is the difference)Primary key class

Are, for the near term, generally less portable between Enterprise JavaBean (EJB) servers


Use bean-managed persistence when container-managed persistence does not do what is needed. For instance, you might need to talk to a database that is not supported for CMP, or want to store data in something that is not a database. For example, a PhoneBook bean, which does bean-managed persistence, stores its information as serialized Java (.ser) files on the filesystem. There is no way to do that in a CMP bean.

When writing an BMP bean, provide the same pieces that you provide for a CMP bean:

Home and remote interfacesA bean classA primary key class

The only place you will see a difference is in the bean class. The interfaces and key class are not affected by how the bean manages its persistence.

DB2 and Oracle allow columns other than the primary key to be null by default.

Sybase does not allow columns to be null by default. Therefore when creating an EJB all fields must be set to non-null values to avoid database exceptions.

You can change Sybase behavior using the following script (substitute dbname for the name of the database that contains your tables).

Database Table Column Defaults

use mastergosp_dboption "dbname", "allow nulls by default", truego use dbnamegocheckpointgo



Transaction Basics


Transaction: A Definition

A transaction is a set of operations that moves data from one consistent state to another.

The set of operations becomes an indivisible unit of workAllows the bundling of discrete operations


The word transaction has a specific meaning in the context of this course.

A transaction is a set of operations that transform a set of data from one state to different but consistent state. In the definition presented here, the word set is important; a transaction can involve many separate operations. If the end result is to be consistent with the starting state, we need a way to bundle that set of operations together so they become indivisible.

As a very simple transaction, consider a transfer of money between one bank account and another. The implementation may be very complex or very simple; this could be an end-of-day reconciliation of international funds between two huge banks, or it could be an individual accountholder moving money from saving to checking. The ultimate goal is to move money between two accounts without losing or gaining any.

A transfer can be analyzed into two operations: a deduction from one account and a deposit into another. There needs to be a way to ensure that both of these operations happen. If either one fails, the other must also be undone. This is necessary to guarantee consistency (which in this case simply means that the same total exists before and after the transfer).

DefinitionsTransactional client

An arbitrary program that can invoke operations on many transactional objects in a single transaction.

Transaction managerTakes care of managing transactions behind the scenes.

Resource managerManages the transaction for a single data source.

Transactional objectAn object whose behavior is affected by being invoked within the scope of a transaction.

EJBs may be transactional objects.


These definitions are from the OTS specification.

Transaction Context

A single distributed transaction can involve multiple objects and multiple operations.

A transaction context:Represents the transaction shared by participating transactional objects.Is automatically propagated (usually) to transactional objects as they are used.Allows synchronization of affected transaction objects at commit or rollback.


The EJB specification declares that a single context can be distributed across multiple machines.

Java and TransactionsA transaction is a unit of work that has the following characteristics (the ACID properties):

Atomic: if interrupted by failure, all effects are undone (rolled back)Consistent: effects of a transaction preserve invariant properties Isolated: intermediate states are transparent to other transactions; transactions appear to execute seriallyDurable: effects of a completed transaction are persistent and never lost

The Java Transaction Service (JTS)Implements the Java mapping of OMG OTS

The Java Transaction API (JTA)Specifies local Java interfaces between a Transaction Manager and the parties


A transaction is a unit of work that may take place in a single process or multiple processes connected by a network. It has the following characteristics:

Atomicity guarantees that the set of operations will occur as an all-or-nothing proposition. The transaction will not leave any work partially completed. If the transaction cannot complete all the work, then any work it could complete will be undone, leaving the system as if the transaction had never been attempted.Consistency guarantees that, if you correctly implement that transaction, the system will leave data in a consistent state. Notice that this does not mean that the transaction can guarantee accuracy. If you mis-implement a transfer so it deposits to (or deducts from) both accounts, your data is going to end up inconsistent. The transaction system does not know the semantics of your application. But as long as your code does the right thing, the before and after states of the data will be consistent.Isolation guarantees that in-flight transactions will be properly protected from each other, even if they are running in parallel. In other words, one transaction will not be allowed to see the working state of another's data. This is important because otherwise, one transaction could make a decision based on a change that was later rolled back. Concurrent transactions must run as if they are the only ones.Durability guarantees that, once a transaction has successfully completed its work, the effects of that work will not be lost. In other words, it will be possible to recreate the data if it is modified (by a transaction that later aborts) or lost (due to something like a media failure).

The transaction model used in the EJB specification is based on the OMG OTS (Object Transaction Service) 1.1 specification, which is based on the X/Open model described in the XA specification. The XA specification describes a model of distributed transactions that delegates the maintenance of the ACID properties to the transaction manager, leaving the application programmer free to work on the logic of the application rather than managing distributed transactions. It also describes interaction with resource managers like databases.

The Java Transaction Service (JTS) implements the Java mapping of OMG OTS and specifies the implementation of a transaction manager (TM) that supports the JTA specificationThe Java Transaction API (JTA) specifies local Java interfaces between a Transaction Manager and the parties involved in a distributed transaction system (Application, Resource manager and Application server).The EJB specification requires a partial implementation of JTA. This hides most system complexity from the programmer.

Transaction Manager

Resource Manager A

Resource Manager B

1. prepare 1. prepare

2 I'm prepared 2. I'm prepared

Transaction Manager

Resource Manager A

Resource Manager B

1. commit or abort

1. commit or abort

2 OK 2. OK

Phase IThe Prepare Phase

Phase IIThe Resolution Phase

Distributed Transaction - Two-Phase Commit


This slide shows the two-phase commit protocol that allows multiple resources to update within a distributed transaction:

1. In Phase I, the coordinator sends a message to each participant to prepare to commit.

2. In Phase II, the coordinator tallies the responses. If all participants are prepared to commit, the transaction commits; otherwise, the transaction is rolled back. If the Resource Managers are for the same database, WebSphere Advanced Edition will optimize the transaction to single-phase commit.

Distributed transactions are more complex than local ones. In a distributed transaction, you must not only ensure the ACID properties for a single process, but you must ensure them across a set of processes on a network. In a local transaction, the only component that can fail is the process itself. In a distributed transaction, any one process or the network connecting them can fail. In the EJB model, however, the responsibility for managing distributed transactions falls to the provider of the EJB server and container. The application programmer doesn't need to worry about it.

Two-phase commit is a protocol that allows multiple resources to update within a single transaction:

It allows the outcome of the transaction to be negotiated by all participants (necessary for ACID properties)It involves two sets of messages between the transaction manager and the resource managers

For more information about distributed two-phase commit processing, see: http://www.sei.cmu.edu/activities/str/descriptions/dtpc_body.html

Transactional DB SupportJava Transaction API (JTA) Drivers:

DB2 6.1 with Fixpack 4Sybase 12.0

Must have transaction log to useProvided by admin server

Waiting for other DB vendors to catch up

JDBC 1.x drivers get one-phase commit (1PC)Connection opened in batch commit modeConnection committed when transaction commits, aborted when transaction abortsGood if only single DB in server, but broken if distributed application with multiple DBs


JDBC/XA provides a standard two-phase commit API for multiple databases. However, XA support is part of JDBC 2.0 (which is part of Java 2). WebSphere 3.0x uses Java 1.1.x, whereas WebSphere 3.5 uses Java 1.2.Two-phase commit to Oracle is not supported in WebSphere v3.0x because a suitable JDBC driver for Oracle is not available.Transaction logging is implemented by the "tranlog" service that is provided by the administrative server.Version 3.0x

WebSphere 3.0x supports two-phase commit to DB2 through a JDBC/ODBC bridge that communicates directly with a JTA (Java Transaction API) interface.DB2 6.1 with Fixpack 4 includes a JTA enabled JDBC driver which implements a subset of the JTA 1.0 spec. This is a pure Java implementation.These DB2 drivers are based on Java 1.1.x. Thus, support for 2PC with DB2 does not depend on XA support in JDBC 2.0 drivers.

Version 3.5DB2 6.1 with Fixpack 4Sybase 12.0 (on some, but not all platforms)

WebSphere Family Interoperability

Transactions that include EJBs running in both the Enterprise Edition/Component Broker (EE/CB) server and the Advanced Edition (AE) server, require special flags to be set in the AE server. "-Dcom.ibm.ejs.jts.jts.ControlSet.nativeOnly=false""-Dcom.ibm.ejs.jts.jts.ControlSet.interoperabilityOnly=true"


WebSphere Data Sources For 2PC

With respect to WebSphere Enterprise Editon/Component Broker 3.5, the adapters that support two-phase commit are:

DB2 (through the native DB2 driver which uses XA) Oracle (through the native Oracle Driver which uses XA)APPC (through sync. level 2 Communication Server support)MQ (through the native MQ XA driver)

With respect to WebSphere Advanced Edition 3.5, JDBC is used for their persistence mechanism. The JDBC drivers that support 2PC are:

DB2 6.1 JTA driver (recommended)


Provides uniform access to a wide range of relational databasesJ2EE specification requires JDBC 2.0 core and extensionsWebSphere supports JDBC 2.0.

Java DataBase Connectivity (JDBC)


JDBC technology is an API that lets you access virtually any relational data source from the Java programming language. It provides cross-DataBase Management System connectivity to a wide range of SQL databases, and with the new JDBC 2.0 API, it also provides access to other relational data sources, such as spreadsheets or flat files. The JDBC API allows developers to take advantage of the Java platform's "Write Once, Run Anywhere" capabilities for industrial strength, cross-platform applications that require access to enterprise data. With a JDBC technology-enabled driver, a developer can easily connect all corporate data even in a heterogeneous environment. JDBC API makes it possible to do three things:

Establish a connection with a database or access any relational data sourceSend SQL statementsProcess the results

IBM WebSphere supports JDBC plus extensions today and distributes DB2 as part of the product for use as persistent storage. Distributed database transactions are supported across homogeneous DB2 servers or Oracle servers.

Database Driver Class Table

DB Class URL Prefix JTA 2PCDB2 6.1DB2 AS/400

com.ibm.db2.jdbc.app.DB2Driver jdbc:db2 false no

DB2 6.1DB2 AS/400

com.ibm.db2.jdbc.app.DB2Driver jdbc:jta:db2 true yes

Oracle oracle.jdbc.driver.OracleDriver jdbc:oracle:thin:@<db_hostname>:<port_number>

false no


Other databases with JDBC drivers can be used by servlets and for bean-managed persistence (BMP).

Refer to the documentation for which driver to use. For DB2/390, see Chapter 2 of the "Application Programming Guide and Reference for Java" at the following URL:ftp://ftp.software.ibm.com/software/os390/db2server/books/DSNJV0G2.PDF

DB2 6.1 is recommended for distributed transactions and two-phase commits.

WebSphere 3.5 Database Compatibility Sheet

DB2 6.1 JTA/2PC Persistence(CMP/BMP)

Repository Support

Admin Server Failover

Admin ServerAuto Reconnect

AIX Yes Yes Yes Yes Yes (fixpack4)

Solaris Yes Yes Yes Yes Yes (fixpack4)

HP-UX No (?) Yes Yes Yes Yes (fixpack4)

NT/x86 Yes Yes Yes Yes Yes (fixpack4)

OS/390* Yes (DB2 Connect)

BMP only Yes (untested) Yes (untested) Unknown

AS400* Yes Yes Yes No Yes

NOTE: OS/390 and AS/400 have productspecific release structuring for DB2


Above and on the next two slides you can find sheets that describe certain compatibility issues regarding WebSphere and certain wide use database management systems.


Oracle JTA/2PC Persistence(CMP/BMP)

Repository Support



AIX No (Oracle limitation)

Yes Yes Yes Yes

Solaris No (Oracle limitation)

Yes Yes Yes Yes

HP-UX No (Oracle limitation)

Yes (?) Yes Yes Yes

NT/x86 No (Oracle limitation)

Yes Yes Yes Yes

OS/390 No (Oracle limitation)

Yes (unsupported) Yes (unsupported)

Yes (unsupported)

Yes (unsupported)



Sybase ASE11

JTA/2PC Persistence(CMP/BMP)

Repository Support



AIX Yes Yes Yes Yes Yes

Solaris Yes Yes Yes Yes Yes

HP-UX No (unsupported) Yes (unsupported) Yes (unsupported)

Yes (unsupported)

Yes (unsupported)

NT/x86 Yes (unsupported)

Yes (unsupported) Yes (unsupported)

Yes (unsupported)

Yes (unsupported)



EJB Distributed Transaction Support


IBM presently supports EJB specification 1.0 with 1.1 drivers.

Transactions and EJBs

A key feature of Enterprise JavaBeans (EJB) is support for distributed transactions.

The burden of managing transactions is shifted to the container and EJB server provider.

EJB supports flat transactions.Modeled after the OMG Object Transaction Service V1.1 (OTS)


Distributed transactions are more complex than local ones. In a distributed transaction, besides ensuring the ACID properties for a single process, the properties must be ensured across a set of processes on a network. In a local transaction, the only component that can fail is the process itself. In a distributed transaction, any one process or the network connecting them can fail. In the Enterprise JavaBean (EJB) model, however, the responsibility for managing distributed transactions falls to the provider of the EJB server and container. The application programmer does not need to worry about it.

The EJB specifications (1.0 and 1.1) describe a "flat" model of transactions, (top-level transactions only), with no subtransactions. Another model allows nested transactions in which a transaction may have subtransactions, (a parent-child relationship). This model offers better granularity, but it is not consistently supported across the industry.

The transaction model used in the EJB specification is based on the OMG (Object Management Group) OTS (Object Transaction Service) 1.1 specification, which is based on the X/Open model described in the XA specification. The XA specification neither describes nor supports true nesting, and neither do the models that are based on it.

Transactions in Enterprise Beans

EJB specification supports distributed transactionsAvailable to both session and entity beans

Container implements the transaction demarcation and management

Developer declares the transaction semanticsYou will set these in the lab - be careful with this

EJB server and container provide the low-level servicesTwo-phase commitInteractions with databasesTransaction propagation


In the typical bean, the programmer uses the deployment descriptor to specify (declare) the required transaction semantics. The container generates the necessary support code. Such applications are said to use container-managed transactions.

Programmers can get access to the transaction-demarcation API, if desired. Such an application is said to use bean-managed transactions rather than container-managed transactions.

Other combinations of these are possible.

Transaction Demarcation

The EJB model offers a variety of ways to make use of transactional services

Transaction demarcation determines who is responsible for starting and completing a transaction

Container demarcation, available forEntity beansSession beans

Bean demarcation, available only forSession beans

Client demarcation

Explicit transaction management


This section describes how to get the benefits of transactions in your enterprise beans (or for applications that use enterprise beans).

Transaction Demarcation Scenarios

Client EJB

business method

Each method is a transaction (implicit)

Implicit using declare

specification


The usual case with enterprise beans. Each bean tells the container which transactional services it needs and the container provides them.

UserTransaction

Client EJB

begin()

business method

commit()

The client delineates the TXN start and end. (explicit)

Client demarcation

Client Demarcation Scenarios


Client acquires a UserTransaction through a JNDI lookup:InitialContext ic = new InitialContext(properties);javax.transaction.UserTransaction = ic.lookup(jta/usertransaction");

Client begins a transaction This creates a new transaction context that is associated with client thread.

Client calls operations on objectsTransactional objects are implicitly associated with a client’s transaction by sharing the same transaction context.

Client issues commitTransactional objects that are associated with context are now told to begin the commit processing.

Session Bean Scenario

Client Session Bean UserTransaction

EJB

business method begin()

business method

commit()

Session bean delineates TXN begin and end.(explicit, TX_BEAN_MANAGED)

Bean-Managed Demarcation


A Session EJB can use a UserTransaction if its transaction attribute is set to TX_BEAN_MANAGED.

The UserTransaction is acquired from the SessionContext.javax.transaction.UserTransaction = sessionCtx.getUserTransaction();

In stateless session beans, a method that starts a transaction is not allowed to return if the transaction is still active

In stateful session beans, a method can start a transaction and return, leaving the transaction active

Transactional Specifiers

For container-managed transactions, a bean indicates its requirements through two attributes

The transaction attributeDefines the transactional requirementsCan be set for the bean or for individual methods(with one exception)

The transaction-isolation attributeDetermines how transactional reads (only) are isolatedCan be set for the bean or for individual method


These two transactional specifiers, the transaction attribute and the isolation attribute, are set in the deployment descriptor. When the bean is deployed, the container generates the necessary transaction-support code. The values chosen for these specifiers give the container the information it needs to generate that support code.

The transaction attribute indicates the transactional requirements for beans. Clients need to know things like, "Can I call them outside of a transaction? Can I require them to start new transactions?" The value of this attribute answers those questions.

The isolation attribute simply affects how database locks are held for reads that occur within transactions. This provides the ability to sacrifice accuracy of reads in favor of greater concurrency at the database. It does not affect updates because no option to sacrifice accuracy for concurrency exists there. Transactional updates are always properly isolated.

Transaction Attribute

This attribute determines if and how transactions are needed.

Takes one of six possible values:

TX_MANDATORYTX_REQUIREDTX_REQUIRES_NEWTX_SUPPORTSTX_NOT_SUPPORTEDTX_BEAN_MANAGED


The first five possible values indicate container-managed transactions, and these can be applied to an entire bean or to individual methods within a bean.

The TX_BEAN_MANAGED value indicates that the bean itself, rather than the container, assumes responsibility for starting and ending transactions. This is a bean-managed transaction. In version 1.1 of the EJB specification, only session beans can request bean-managed transactions. This value applies to the entire bean, and cannot be specified for individual bean methods.

The EJB specification V1.1 also adds a seventh possible value, TX_NEVER. This value requires the container to throw an exception if the client calls a method from within a transaction context. This is not supported by WebSphere 3.0.

Values for the Transaction Attribute

TX_MANDATORY: The container must call methods from the transactional context established by the client.

If the client has a transaction context, it is propagated to the bean. If the client does not have a transaction context, the container throws TransactionRequiredException.



TX_REQUIRED: The container must invoke methods within a transactional context.

If the client has a transaction context, it is propagated to the bean.If not, the container starts a transaction.

TX_REQUIRES_NEW: The container must start a new transaction for the method.

If the client has a transaction context, it is suspended for the duration, and a new one is started.If not, the container starts a transaction.



TX_SUPPORTS: The container must use aclient's context for the transaction.

If the client has a transaction context, it is propagated to the bean.If not, the activation is made non-transactionally.

TX_NOT_SUPPORTED: The container mustnot invoke methods transactionally.

If the client has a transaction context, it is suspended for the duration.If not, the container starts the method (a local transaction).


TX_SUPPORTS may be used to perform optimization based on the existence of transaction context.

Transaction Attribute Summary


The transaction attribute defines the transactional manner in which the container invokes enterprise bean methods. This attribute can be set for the bean as a whole and for individual methods in a bean.

TX_MANDATORY: Directs the container to always invoke the bean method within the transaction context associated with the client. EJB clients that access these entity beans must do so within an existing transaction.

TX_NOT_SUPPORTED: Directs the container to invoke bean methods without a transaction context. If a client invokes a bean method from within a transaction context, the container suspends the association between the transaction and the current thread before invoking the method on the enterprise bean instance. The container then resumes the suspended association when the method invocation returns.

TX_REQUIRES_NEW: Directs the container to always invoke the bean method within a new transaction context, regardless of whether the client invokes the method within or outside of a transaction context.

TX_REQUIRED: Directs the container to invoke the bean method within a transaction context. If a client invokes a bean method from within a transaction context, the container invokes the bean method within the client transaction context. If a client invokes a bean method outside of a transaction context, the container creates a new transaction context and invokes the bean method from within that context.

TX_SUPPORTS: Directs the container to invoke the bean method within a transaction context if the client invokes the bean method within a transaction. If the client invokes the bean method without a transaction context, the container invokes the bean method without a transaction context.

Transaction Isolation Attribute

Applies only to read operations

Takes one of four possible values:TRANSACTION_READ_UNCOMMITTEDTRANSACTION_READ_COMMITTEDTRANSACTION_REPEATABLE_READTRANSACTION_SERIALIZABLE

Allow tradeoff between accuracy of reads for concurrency


The isolation attribute tells the container how to limit concurrent transactional reads at a database. The container applies isolation attribute as follows:

For entity beans with CMP: The container generates code that assures the desired level of isolation for each database access.

For session beans and BMP entity beans: The container sets the isolation level at the start of each transaction, for each database connection.

Anomalous Read Phenomena

Three types of read anomalies can occur under different transaction-isolation settings:

Dirty read: T1 reads data that has been modified by T2, before T2 ends.Non-repeatable read caused by fine-grained locks.

T1 reads a record and drops its lockT2 updates; T1 rereads different data

Phantom read: A non-repeatable read involving a range of data and inserts or deletes on the range.


A phantom-read scenario is:

1. T1 reads a set of records that match some criterion.2. T2 inserts a record that matches the criterion.3. T1 continues processing the set, which now includes records that were not part of the original matching set.

Avoiding Anomalous Reads

TRANSACTION_READ_UNCOMMITTED:Permits all the read anomalies

TRANSACTION_READ_COMMITTED:Forbids only dirty reads

TRANSACTION_REPEATABLE_READ:Forbids both dirty and unrepeatable reads

TRANSACTION_SERIALIZABLE:Forbids all the read anomalies


Transaction Isolation Variations

Read Uncommitted

Read Committed

Repeatable Read

Serializable

DB2 x x x xOracle x xSybase x x x

rs = select balance from account where owner = Name

rs.next()oldBalance = rs.getDouble("Balance")newBalance = oldBalance + 10.0update account ^ set balance = ? where owner =

Namers.close()

rs = Result Set^ = holdlock for Sybase


The example on the slide illustrates a deposit of $10 to a savings account. The slide does NOT depict true code, it merely provides the "how it works" sequence.

This slide shows that databases may not support all the isolation levels.

Refer to Appendix G for details on the differences in locking behavior.

DB2/400 supports five isolation levels -

COMMIT(*RR) - Repeatable Read (RR) - In the ANS and ISO standards, Repeatable Read is called Serializable. COMMIT(*RS) - Read Stability (RS) - In the ANS and ISO standards, Read Stability is called Repeatable Read.COMMIT(*CS) - Cursor Stability (CS) - In the ANS and ISO standards, Cursor Stability is called Read CommittedCOMMIT(*CHG) or COMMIT(*UR) - Uncommitted Read (UR) In the ANS and ISO standards, Uncommitted Read is called Read UncommittedCOMMIT(*NONE) or COMMIT(*NC) - No Commit (NC)

For a detailed description of record lock durations, see Table 20-1 in the book DB2 UDB for AS/400 SQL Programming, SC41-5611-02

For more details on DB2 UDB for AS/400 Isolation levels, seehttp://as400bks.rochester.ibm.com/pubs/html/as400/v4r4/ic2924/info/db2/rbafzmst29.htm

WebSphere Transaction Isolation Behavior

Transaction isolation level is tied to a DB connection, and the connection will use the isolation level that is specified in the first bean that is accessed through the connection.

For CMP managed entities, if your attribute calculation (update) depends on the value you read not changing until your do a write, then you need to use an isolation level of REPEATABLE_READ or SERIALIZABLE.

With the READ_COMMITTED isolation level, the behaviors of DB2 and Oracle are considerably different for simple cases involving an entity EJB in WebSphere. With DB2 updates, the row lock is not held after the read (because WebSphere closes the resultSet); with Oracle the row lock is held.

Refer to the appendix on Concurrency. It has a diagram that helps explain this issue.


Developing EJBs for deployment on both WebSphere Enterprise Edition/Component Broker and WebSphere Advanced Edition requires that you use only the EJB functionality that is supported by both products.

These implementations are based off the 1.0 version of the EJB specification and both implement portions of the 1.1 specification. But there are differences between the two implementations.

Use of Container Managed Persistence (CMP) is the recommended for Entity bean development because it is more portable, provides abstraction, and reduces code maintenance cost.

The "Writing Enterprise Beans in WebSphere" book contains a section that list restrictions associated with the EJB server (Component Broker) environment.

Features in VA-J like inheritance and associations are available with version 3.02.1.

WebSphere Family EJB Portability


Future Direction

Portability will be made easier.

EJBs developed and unit tested in VisualAge for Java will run without change on the WebSphere Family of application servers that support EJBs. No code porting or "re-deployment" will be required.

This is true today for WebSphere Advanced Edition 3.X (platforms include AS/400, AIX, NT, and Solaris).



Big3

08/24/00 © Copyright 2000 IBM Corporation Big3.PRZ 1

Big3 Application

Big3 - small insurance applicationSimple presentation and business logicContains enough components for testing various configurations


Big3 Application

Big3 business logic consists of:Three Enterprise JavaBeans:

ProcessClaim (stateless session bean)Policy (container-managed entity bean)Claim (container-managed entity bean)

Presentation logicServlet/HTMLJava client


Big3 Application

Front-tierPresentation

ProcessClaim Servletor Java Client

Back-tierRDB

Session Bean

Policy no.AmountPremium

Claim no.AmountState

Database

Policy bean

Claim beanKeys

Middle-tierBusiness Logic

ProcessClaim


1. The ProcessClaim session bean can be invoked by a standalone Java application, a servlet, JSP, or HTML.

2. The ProcessClaim session bean creates the Policy and the Claim enterprise JavaBeans.3. The Policy bean holds the customer policy data:

1. Policy number (key field)2. Policy amount3. Policy premium

4. The Claim bean contains customer claim data:1. Claim number2. Amount of claim3. State

5. When an insurance company employee is using the Big3 application to view and modify customer information, the ProcessClaim servlet sends a request to the processClaim bean. This bean manages session information. If the customer has a claim, the business logic computes a new premium.

6. Once new claim or policy information is entered and committed, it is written to the database. In this example, both the policy and the claim data reside in the same database. It is possible to create separate databases for policy and claim data. The separate databases may or may not reside on the same physical node.

7. The information on Tier 1 and the processClaim bean are not persistent. The Policy and Claim bean information is persistent.

Object Interaction Diagram

ClientClaim Policy

ProcessClaim

processClaimsetPremium

setAmount


This diagram shows what is happening inside the Big3 application when the client requests processClaim.The client can be either servlet/HTML-based, or a Java client.

Tools We'll Use

The following tools will be used during the labs:

WebSphere Application Server Advanced Edition, Version 3.5IBM Network Dispatcher (ND)VisualAge for Java Enterprise EditionManual EJB packaging: jetace


We will also talk about SecureWay Directory Services (LDAP). Firewalls will be discussed but not installed.


Deploying Applications

08/24/00 © Copyright IBM Corporation 2000 Deploying Apps.PRZ 1

An (enterprise) application consists of:Enterprise beansWeb Applications (including Servlets)Web resources (e.g. HTML or JSP files)

The combined application:Can be started and stopped as a single unitCan have security applied

Group related resources in the same application if they should be available together and are used by the same users

Put resources in separate applications that are used by different users or should be available independently

Planning Applications


An enterprise application (often referred to as just an application) combines Web application servlets and Web resources with enterprise beans as one named entity that can be managed as a unit.As an administrator, you have to consider how to organize and administer the files in the WebSphere administrative domain. There are two important factors to consider when creating an application: availability and security.After you use the console to configure an application, you can start and stop the resources in the application in unison by starting and stopping the application. It is tempting to configure multiple resources into one large application so that you can make all available in a single step. However, it is often the case that resources will have different users or need to be available at different times.It makes sense to configure an application with the resources that must be available together and are used by a common set of users. This way, you can take one application off-line to perform maintenance without affecting the users of other applications.In terms of security, there are security settings that apply to the whole application, such as the challenge type, and access control on the individual methods of the resources. If you configure all resources in the same application, they must use the same challenge type, which may not be desirable in all cases.

WebSphere Studio Publishing

WebSphere Studio supports staging and publishing to different/multiple servers

Provides local and remote publishing of web site filesProvides separate publishing paths by asset

Servlets and JavaBeansPages (HTML and JSP)Other


WebSphere Studio supports a Publishing Function, the copying of files from the source directories in the development team project file structure to the appropriate directories on the Web Server and Application Server nodes.In order to help with proper Configuration Management Principles of testing and migration to production, WebSphere Studio utilizes the concept of "stages". The stages allows the Studio user to publish to different directory structures and servers for either test or production environments.If, as an administrator, you are supporting developers utilizing WebSphere Studio you should supply the development team with appropriate file destinations for publishing.

File Locations

Create deployable or deployed JAR files for Enterprise beansDefault locations: <as_root>/deployableEJBs and <as_root>/deployedEJBs

Create a "servlet" directory for servlets and other Java classesThis directory will be in the Web application's classpathIf enterprise beans depend on these classes, add this directory to the node's classpath

Create a directory for non-reloadable Java classesThis directory will be in the Application Server's classpath

Create a "web" directory for JSP files and static contentThis directory will be the Web application's document rootIf you want to serve static content through WebSphere a file servlet must be configuredIf you want to serve static content through your Web server, create a directory for that content


WebSphere Application Server does not provide any tools for managing files and directories. This means that you must plan how your applications will be structured and copy the files and directories to the correct locations on each node.The Deployed EJBs directory for a node is configured in the node's properties so that EJBs can be deployed from an Administrative Console on a remote machine.When a Web application is created, it has a document root and classpath. There are defaults for these directories, but you can specify any directory you wish.Some Java classes should not be located in the Web application's classpath so you may need to locate them in a separate directory and add that to the Application Server's classpath.

EJB Code + .ser file, manifest

EJB Code + .ser file, manifest + deployed classes

VA-J EE: EJB -> Export -> Deployed JAR

VA-J EE: EJB -> Export -> EJB JAR

JETACE

WAS AE Console: Create EJB

Deployable EJB JAR file

Deployed EJB JAR file

EJB Code

Deploying EJBs


To use EJBs with an EJB Server, they must be deployed. This process creates a JAR file including:EJB code (EJB class, home and remote interfaces)Deployment descriptor (.ser file - defines the session or entity bean properties)Manifest (lists the content of the JAR file)Deployed classes (ORB, stub, and skeleton classes)

To create a deployed EJB JAR file, either:Use VisualAge for Java Enterprise EditionUse the jetace tool and WebSphere Application Server.

If you only have a JAR file (or directory) containing the EJB code, you can manually create a deployable JAR file using the jetace tool which is included with WebSphere Application Server.If you have a deployable JAR file, WebSphere Application Server will automatically deploy it when you create an Enterprise Bean in the console.

jetace


The jetace tool is included with WebSphere Application Server. You can start this from a command prompt by entering the command: jetace jetace allows you to load EJB code from a JAR file or directory. For each EJB you can specify the EJB settings:

Basic - The deployed name, the class names of the bean, home and remote interface, and the JNDI name that will be used to access the bean.Entity - Primary key class and the list of container managed fields (for BMP or CMP entity beans).Session - Session time-out and state management setting (for session beans).Transactions - Transaction attribute and isolation level.Security - Run-As mode and identity.Environment - Environment variables.Dependencies - Class dependencies.

When you save the EJB, jetace creates a deployable JAR file including the EJB code, a .ser file and manifest.WebSphere Application Server will create deployed classes if they do not already exist when you load this deployable JAR file.

Create an Application Server


You can create an application server from:The Wizard icon - start the Create Application Server wizard. This wizard will allow you to create an application server and its EJBContainer, Enterprise Beans, ServletEngine and WebApplication.The Type view - select Application Servers under Nodes and select Create from the context menu.The Topology view - select a node and select Create -> Application Server from the context menu.Console - select Tasks-->Create Application Server to start the wizard.The General tab allows you to specify the application server name and properties for the JVM.The Advanced tab allows you to specify tracing and performance data collection settings.The Debug tab allows you to enable debugging or Object Level Trace (OLT).

The wizard will guide you through several steps as you define your application server.

Create an EJB Container


You can create an EJBContainer from:The Create Application Server wizard.The Type view - select EJBContainers under Nodes, Application Servers and select Create from the context menu.The Topology view - select an Application Server under a node and select Create -> EJBContainer from the context menu.

The General tab specifies the container name.The Advanced tab specifies settings for the bean cache.The DataSource tab defines the default data source for all entity beans in the container. A user ID and password can be supplied if necessary.

Create Enterprise Beans


You can create an Enterprise Bean from:The Create Application Server wizard.The Type view - select EnterpriseBeans under Nodes, Application Servers, EJBContainers and select Create from the context menu.The Topology view - select an EJBContainer under an Application Server and select Create -> Enterprise Bean from the context menu.

The General tab specifies the bean name and JAR file. Use the Browse button to select a deployable or deployed JAR file. Use the Edit button to view the deployment descriptor. Select the desired database access mode to control how entity bean values are cached. From 3.02 you can choose:

Exclusive - Option A caching in the EJB spec.Shared - Option C caching in the EJB spec. This is the default.

The Advanced tab defines the pool size for the bean instances. In general, WebSphere tries to optimize Enterprise Bean access by re-using existing beans where the semantics of the EJB specification allow it. Note that the maximum is not a hard maximum, but the maximum number of instances that will be held alive. The Find for Update field specifies the locking behavior of the bean: it is designed to reduce deadlock when beans are updated. Normally, when a findByPrimaryKey is issued, WebSphere puts a shared lock on the database row, and then if the client updates the bean, WebSphere converts it to an exclusive lock. If two transactions run at the same time, deadlock occurs. If this is likely to happen, specifying "Find for update" will cause WebSphere to use an exclusive lock when the find is issued, avoiding deadlock.The Parent tab defines the EJB Container in which the Enterprise Bean is deployed.The DataSource tab defines the database where entity beans store their values. A user ID and password can be supplied if necessary. The fields are greyed out for session beans.

Browse EJB JAR files

Open JAR file to deploy all beans in it

Double-click JAR file to browse its contents

If JAR file has not been deployed, a pop-up will ask if you want to deploy it now


When you use the Browse button to select a deployable or deployed JAR file, it browses the Deployed JAR Directory on the node. This directory can be set in the Node properties.An EJB JAR file can contain multiple EJBs. If you just select a JAR file and click Open, all beans in the JAR file will be deployed with default values. This may not be appropriate in all cases.If you double-click on a JAR file, the JAR file will be opened and the deployment descriptors in it will be listed. You can then choose a single bean to be deployed.If the JAR file has not been deployed, (that is, it contains the bean code, deployment descriptor and manifest but no client/server stubs) WebSphere will ask if you want to deploy the JAR file now. It will create and compile the stubs and build a new deployed version of the JAR file. If the original JAR file was named Increment.jar then the deployed JAR file will be named DeployedIncrement.jar.

Create a Servlet Engine

Transport settings control the queue of requests from the Web server plug-in to the Servlet Engine


You can create a ServletEngine from:The Create Application Server wizard.The Wizards icon - start the Create Servlet Engine wizard.The Types view - select ServletEngines under Nodes, Application Servers and select Create from the context menu.The Topology view - select an Application Server under a node and select Create -> ServletEngine from the context menu.

The General tab specifies the servlet engine name and the application server in which it runs.The Advanced tab specifies the settings controlling communication between the Web server plug-in and the servlet engine.You can specify a queue type of OSE, HTTP, or None.

The queue sends servlet requests to a specific port.The maximum connections specifies how many concurrent requests can connect between the Web Server plug-in and the servlet engine.

If queue type is OSE, you can configure its transport (Local Pipes, INET Sockets or Java TCP/IP), logging and queue name.

Web Server Plug-in Configuration

The queue configuration for all ServletEngines is written to three properties files in the <as_root>/temp directory

This is done each time an application server is restarted

Web server plug-in loads these properties files periodicallyose.refresh.interval in bootstrap.properties (default 20 seconds)

When you change resources in the WebSphere Administrative Domain, the plug-in will only see the changes after the next refresh


On a production system where the configuration is fairly static, it is recommended to change this interval to several minutes to reduce the overhead of refreshing the configuration.If the Web applications are not behaving correctly, it may be that the plug-in configuration is out of step. You can regenerate the plug-in configuration from the Advanced tab of the ServletEngine properties in the console.

Sample Plug-in Property Files

vhosts.properties -- Maps aliases to virtual hostslocalhost=default_host127.0.0.1=default_hostwasedu=default_host

rules.properties -- Maps configured URIs to queuesdefault_host/WebApp1/Servlet1=ibmoselink1default_host/WebApp2/Servlet2=ibmoselink2

queues.properties -- Maps existing queues to portsose.srvgrp=ibmoselink1,ibmoselink2ose.srvgrp.ibmoselink1.clonescount=1ose.srvgrp.ibmoselink1.clone1.port=8110ose.srvgrp.ibmoselink1.clone1.type=local


The Open Servlet Engine (OSE) property files are described as follows:

vhosts.properties -- Maps aliases to virtual hostsrules.properties -- Maps configured URIs to queuesqueues.properties -- Maps existing queues to ports

In general, each servlet engine has its own queue.

These files tell the Web server plug-in how to handle requests. In most cases, you should not edit these files, but the information they contain may be of use when resolving problems.

OSE Configuration

Application Server1ContainerEJB1

Servlet EngineWebApp1

Servlet1

Application Server2ContainerEJB2

Servlet EngineWebApp2

Servlet2

queueName=ibmoselink1queuePort=8110

WebPath=/WebApp1


WebPath=/WebApp2

HT

TP

Ser

ver

Plu

g-in

Application Server 1 Container EJB1 Servlet Engine 1 WebApp1 Servlet1

Application Server 2 Container EJB2 Servlet Engine2 WebApp2 Servlet2vhosts.properties

rules.propertiesqueues.properties


WebPath=/WebApp1


WebPath=/WebApp2


Servlet Engine 1 is configured with a queue named ibmoselink1WebApp1 is configured with a web path of WebApp1Servlet Engine 2 is configured with a queue named ibmoselink2WebApp2 is configured with a web path of WebApp2

1. Request for wasedu/WebApp1/Servlet1 comes into HTTP server

2. HTTP server passes request to WebSphere plug-in

3. Plug-in checks vhosts.properties for wasedu-finds wasedu=default_host

4. Plug-in checks rules.properties for defualt_host/WebApp1/Servlet1-finds default_host/WebApp1/Servlet1=ibmoselink1

5. Plug-in checks queues.properties for information on ibmoselink1 queue

6. Plug-in places request in ibmoselink1 queue

7. The servlet engine in Application Server 1 takes the request from the queue by listening on Port 8110.

Web Applications

A group of servlets that interact to function as a logical applicationMultiple Web Applications are supported in a single Servlet EngineA Web Application is bound to a particular URL (Web path) in the URL namespaceA Web Application exists under a single Virtual HostServes as the scope of class reloading, configuration, and relative paths within an application

www.mysite.com

/webapp /servlet

/account /transfer /snoop /hello

/create /transfer


URIs under the Web path www.mysite.com/servlet are part of the DefaultWebApp.URIs under the Web path www.mysite.com/webapp are part of a different Web application.The Servlet API 2.1 allows the concept of multiple Servlet Context objects which defines a group of related servlets. This servlet group is referred to as a Web Application. A Web application is the scope of data sharing and class reloading for related servlets.This functionality allows for Virtual Hosting and Relative Paths within the server.A Web application is rooted at a particular point in the URL namespace and its resources (servlets, JSPs and other content) are located below that point.

Create Web Applications

Default paths:Web Path: /webapp/<appname>Document root: <as_root>/hosts/<vhost>/<appname>/webClasspath: <as_root>/hosts/<vhost>/<appname>/servlets


You can create a Web application from:The Create Application Server wizard.The Wizard icon - start the Create a Web Application wizard.The Type view - select Web applications under Nodes, Application Servers, ServletEngines, Web applications, and select Create from the context menu.The Topology view - select a ServletEngine under an Application Server and select Create -> Web Application from the context menu.

The General tab specifies the Web Application name, the servlet engine in which it will run, the virtual host to which it will map, and the Full Web Path under which its servlets will be registered.The Advanced tab specifies the document root for static content and JSPs, the classpath for servlets, an error page to handle servlet errors, properties to pass into servlets, whether the application should support auto reload and whether a shared content should be created so that servlets can exchange data with each other.The Parent tab allows the specification of a the servlet engine which will contain the Web Application.When you enter the Web Application Name, the Web Path, Document Root and Classpath will be automatically filled in.

The Web Path will be /webapp/<appname> so servlets will be accessed from a browser using http://<hostname>/webapp/<appname>/<servletname>.The Document root will be <as_root>/hosts/<vhost>/<appname>/web so JSP files and other content should be located there.The Classpath will be <as_root>/hosts/<vhost>/<appname>/servlets so servlet class files should be located there.

Create Servlets


You can create a Servlet from:The Wizard icon -start the Add a servlet wizard.The Type view - select Servlets under Nodes, Application Servers, ServletEngines, Web applications, Servlets, and select Create from the context menu.

The Topology view - select a Web application under a ServletEngine and select Create -> Servlet from the context menu.

The General tab specifies the servlet name, the Web Application in which it will run, the class name for the servlet, and the Web Paths which can be used to access the servlet. Notice that a single servlet can have multiple Web paths and these names do not need to correspond to the Servlet Class Name.The Advanced tab specifies if any parameters should be passed to the servlet when it starts, whether debugging should be enabled, and whether the servlet is loaded at startup or only on demand.

Servlet Reloading

Web ApplicationClasspath defined when Web application is created

Default: <as_root>/hosts/<vhost>/<webapp>/servletsClasses in classpath will be reloaded if a servlet is updated

Application ServerOn installation classpath contains all files in <as_root>/libClasses in classpath are not reloadableAdd all classes that should not be reloaded to the application server classpath

Edit Application Server PropertiesAdd -classpath parameter to Command Line Arguments


The servlets and non-servlet Java components of an application are loaded by the Application Server's Web application classloader or the system classloader (the JVM classloader).The Application Server classpath is automatically set when you install the product. The default setting for the classpath contains all of the Application Server APIs (the JAR files in the <as_root>\lib directory). When the Application Server starts, the system classloader automatically loads the classes in the Application Server classpath. Those classes are not reloadable. When you configure a Web application, you specify the application classpath, which contains the servlets and their non-servlet Java components.That classloader monitors the application classpath and reloads all of the Java components in that application classpath whenever it detects that a loaded servlet has been updated. You can turn off reloading for an application if desired.If you want to enable reloading for your application, but it uses some Java components whose classes you do not want to be reloaded, add those classes to the Application Server classpath instead of the application classpath. The classes will not be reloaded, but the objects will be.

You must add the following Java components to the Application Server classpath:Java objects that are added to sessions. Such objects are serialized and must not be reloaded.Java classes that call Java Native Interface (JNI) methods. Those classes and any imported classes must be placed in the Application Server classpath to prevent loading errors.Objects passed as arguments for remote calls.

For Version 3, a Web application's scope is its application classpath plus the system classloader classpath. Version 3 does not support remote servlet loading (that is, loading servlets across a network). All of an application's components must be on the Application Server machine.

Create a Servlet EngineTask Wizard Step. . .

Creates a servlet

Enable File Servlet


WebSphere Application Server provides internal (built-in) servlets that you can add to your application to enable optional functions for that application.

Serve Servlets by class name:Invoke a servlet by code namecom.ibm.servlet.engine.webapp.InvokerIn addition to invoking the servlet by servlet Web paths configured via the Administrative Console, the Invoker servlet enables you to invoke servlets by their code (class) names. Using the Invoker servlet is considered a security exposure.

Enable File Servlet:Serve HTML files in the application's document root without adding a pass rule to the Web servercom.ibm.servlet.engine.webapp.SimpleFileServletThis servlet handles files in the application document root whose URLs are not covered by the configured servlet URLs.

Select which JSP version to use:Enable the JSP 0.91 page compiler for processing an application's JSP 0.91 files.com.ibm.servlet.jsp.http.pagecompile.PageCompileServletEnable the JSP 1.0 page compiler for processing an application's JSP 1.0 filescom.sun.jsp.runtime.JspServlet

Using System Servlets

A number of system servlets are available:Error Reporter - formats servlet errorsJSP 0.91 - processes JSP 0.91 pagesJSP 1.0 - processes JSP 1.0 pagesFile - allows static content to be served by WebSphereInvoker - allows servlets to be invoked by class name without being configured


There are a number of system servlets supplied some of which will be automatically assigned to a new Web application and others you can choose to add.The Error Reporter servlet (com.ibm.servlet.engine.webapp.DefaultErrorReporter) will be configured for a Web application by default. It formats stack trace information if a servlet error occurs.The JSP 0.91 servlet (com.ibm.servlet.jsp.http.pagecompile.PageCompileServlet) should be used if you want to run JSPs created for the JSP 0.91 specification.The JSP 1.0 servlet (com.sun.jsp.runtime.JspServlet) should be used if you want to run JSPs created for the JSP 1.0 specification.The file servlet (com.ibm.servlet.engine.webapp.SimpleFileServlet) should be configured if you want to serve static content (HTML files, images, etc.) from WebSphere in order to apply WebSphere security. Note: It is more efficient to serve these files directly from the Web server.The invoker servlet (com.ibm.servlet.engine.webapp.InvokerServlet) allows you to invoke servlets in the Web application's servlet directory by name without them being configured in the admin console. This is useful but has some disadvantages. Servlets invoked this way cannot be monitored by the Resource Analyzer. Allowing invocation of servlets by name is also a security risk.

Create Web Resources

Create Web resources to identify files which need to be handled by a Web application but are not in the normal document root

Task Wizard Add a JSP file or Web Resource Can copy a file to a Web application's document root and setup a Web resource for it


You can create a WebResource from:The Wizards icon - start the Add a JSP file or Web resource wizard.The Type view - select Web Resources under Virtual Hosts and select Create-->Web Resource from the context menu.The Topology view - select the Virtual Host for the resource and select Create -> Web Resource from the context menu.

All you specify when adding a Web resource is the resource name and the virtual host with which it is associated. The resource name is the fully qualified URL path including the web path for the Web application which will process the URL.For example, if I wanted to configure a Web resource to access JSP files with file extension .jhtml in directory /pages under my Web application with Web Path /myapp, I would define a Web resource with name /myapp/pages/*.jhtml.If you are using the File servlet to serve static content, setup Web resources to specify the location of that static content.The Add a JSP file or Web resource wizard can be used to copy a file into the directory structure for a Web application and setup the Web resource to access that file.

Create Enterprise Applications

Task Wizard Create Enterprise Application Combine Enterprise Beans, Web Applications and Web resources

Enterprise Application will appear in topology and can be started and stopped directly


You can ONLY create an Enterprise Application from:The Wizard icon - start the Create Enterprise Application wizard.

Enter a name for the application and specify which Enterprise Beans, Web applications and Web resources belong to the application.The application can now be started and configured for security.

Starting and Stopping Resources

Enterprise ApplicationStart - Starts all associated resources and their parentsStop - Stops only associated resources

Application ServerStart - Starts all resources under the serverStop - Stops the server JVM (and everything running in it)

EJBContainer Start - starts container and its EJBs and server if not startedStop - stops container and EJBs

EnterpriseBeanStart - starts EJB and its container and server if not startedStop - stops EJB

Web application Restart - reloads all active servlets - does not start anything


A number of the resources in the WebSphere Admin Domain can be started or stopped directly.In general, when you start a resource, it starts all resources below it in the hierarchy and if any of the resources above it are not started, it starts them too. When you stop a resource, it only stops resources below it in the hierarchy and leaves other resources running. If you use Enterprise Applications, then most of the time you should start and stop the Applications.If you do not use Enterprise Applications, then you should start and stop Application Servers.Notice that you cannot start or stop Servlet engines, Web applications or servlets. When you configure a new Web application, you need to stop and start the application server. When you configure a new servlet, you can restart the Web application without restarting the server.

Deploy resources into an existing application server or create a new one. Each application server runs a new JVM.

Enterprise beans must be deployed either using VisualAge for Java Enterprise Edition or using the JETACE tool and the WebSphere admin console.

Web applications combine servlets and other resources under a common document root with their own classpath.

An Enterprise Application can include:Enterprise beansWeb applications (and their Servlets)Web resources (Web paths to JSP files or static content)

Summary


IBM WEBSPHERE WORKSHOP - LAB EXERCISE

Deploying the Big3 Application

What This Exercise is About

In this exercise you will deploy the Big3 application in WebSphere and test it using a Java Clientand also through a web browser. The drawing below represents the topology you will set up inthis lab.

Note: The RemoteSRPBean (Remote Servlet Redirector Proxy) will be added by default whenyou create Big3Server. Servlet redirection will be discussed later in the Workload Managementsegment of the course materials.

User Requirement

You must have the recommended versions of software installed. You will also need to haveused ftp to transfer the big3deployed.jar file from your NT machine to the AIX machine.

© Copyright IBM Corporation 2000. All rights reserved.

2000/08/23 14:29:03 IBM WebSphere Workshop - Lab Exercise Deployment.lwpPage 1 of 24

What You Should Be Able to Do

After completing the lab you will be able to use the WebSphere Administrator's Console toconfigure an application server and deploy an application. For this and all other labs you will beusing a configuration where both the Administrative Console and Administrative Server arerunning on the same machine.

Introduction

The Big3 Application is a model of an insurance claim processing application. It consists ofthree Enterprise Java Beans (EJBs) and two clients for the beans: a web client consisting oftwo servlets and several HTML files, and a standalone Java client. The EJBs, along with theirassociated interfaces (Remote, Home) and classes (Implementation, Primary Key), arepackaged in the big3deployed.jar file. The JAR file also contains the manifest and deploymentdescriptor files.

In this lab you will use the Administrative Console to create an EJB Container(Big3EBJContainer) and insert the beans into it. Two of the beans, Claim and Policy, areentity beans that use container-managed persistence. The third, PolicyClaimBean, is astateless session bean.

The web client to the Big3 EJBs is made up of a set of HTML pages that gather informtaionabout the claim to be processed, and two servlets: one that parses the EJBs and invokes theEJBs to process a claim, and another that verifies claim information. The servlets are in theBig3Servlets jar file. The administrator’s console will be used to create a Web Application(Big3WebApp) to place these resources in.

The Java Client, big3client, uses the JNDI and RMI/IIOP protocols to locate and communicatedirectly with the EJBs residing on WebSphere server. The Java Client will be used to test thedeployment of Big3 EJBs.

Exercise Instructions

All the steps will be done on the AIX machine unless otherwise specified. Estimated time 1hour 15 minutes.

The Big3 files are located in subdirectories of the /usr/big3 directory. The files are in thefollowing locations:

� HTML files: /usr/big3/html� Servlet: /usr/big3/servlets

We will move the files to the proper WebSphere directories later in this lab.



Part One: Working with the Administrative Console.

__1. Check to see if the HTTP server is running by executing the command: ps -ef | grep httpIf you only see one process (grep http), the http server is not running. Locate the httpserver install directory by executing the command:

find / -name httpd The path to the httpd file will be displayed. Change to the directory listed (before the“/httpd”) and execute the command:

./apachectl start

__2. Execute the command:find / -name startupServer.sh

This will return the path to the WebSphere startupServer shell script. Make note of thepath before /bin/startupServer.sh. This is the install root for WebSphere. Thisdirectory will be referred to as <as_root> for the rest of this lab.

__3. Start the WebSphere Administrative Server by changing to the <as_root>/bin directoryand executing the command:./startupServer.sh&

The use of “&” causes the script to be run in the background. The process id of theAdministrative Server will be displayed before you are returned to the commandprompt.

Note: Execute the command to start the WebSphere Administrative Server from the<as_root>/bin directory or else the Administrative Server will not start up correctlyand will terminate with error messages.

__4. To view the progress of the Administrative Server, view the <as_root>/logs/tracefile.From the <as_root>/bin directory, execute the command:

tail -f ../logs/tracefilewhich will display the last ten lines of the trace file on a continuous refresh. When yousee the message,

WebSphere Administration server open for e-businessthe WebSphere Administrative Server has started. Use CTRL + C to cancel the tailcommand.

Troubleshooting: <as_root>/logs/tracefile is the administrative server log file. Ifthere are any problems during initialization of the administrative server, errormessages will appear in this log. If this tracefile is not being created, you can addthe following lines to the <as_root>/bin/admin.config file to turn on tracing of theadministrative server: com.ibm.ejs.sm.adminServer.traceString = com.ibm.ejs.server.*=all=enabledcom.ibm.ejs.sm.adminServer.traceoutput = Stdout and restart the WebSphereAdministrative Server. This will output detailed trace information to the tracefile.



__5.After confirming that the HTTP server and administrative server are running, start the Administrative Console. From the <as_root>/bin directory, execute the command:

./adminclient.sh

During the starting of the Administrative Console, a connection is being established with theadministrative server and the administrative server repository is accessed. The repository is adatabase running on either DB2 or Oracle (or Sybase for some platforms). The type ofdatabase, as well as the database name, is specified when WebSphere is installed. Thisinformation, along with the database User ID and password, is stored in the<as_root>/bin/admin.config file. It is very important that this file, along with several otherWebSphere properties files, are protected using the operating system's file permissionmechanism. You can monitor the progress of the Administrative Console in the ConsoleMessages section. After the Administrative Console has completed loading, a Console Readymessage will appear.

The administrator’s console has a toolbar and three frames that display information, propertysheets,and console messages. Almost all the configuration activities can be done through theuse of wizards which are available under the Wizards tool or by clicking the Console menu,then selecting tasks from the drop down menu. The Type view is used for the creation ofWebSphere-specific objects such as datasources and JDBC drivers. The Topology view allowsfor easy access to the various settings for the application and its components. Applications arealso administered from the topology vew. This includes starting and stopping the applicationsand modifying their settings.

Wizards

Type View

Refresh

For more information, refer to “Using the administrative console” available online athttp://www.ibm.com/software/webservers/appserv/library.html



Part Two: Configuring Database support.

The Process and Claim beans are persistent entity beans. They depend on the EJBcontainer to provide access to the database. In this section, we will create theDataSource and JDBC Driver objects. Later on, during the deployment of the beans, wewill associate the datasource with the container.

__1. From the Type view, right-click the JDBCDrivers folder and click Create from the popup menu. This will display the properties dialog where information concerning the JDBCDriver needs to be specified.

Type / Select the following values:

Name: DB2DriverImplementation Class: com.ibm.db2.jdbc.app.DB2DriverURL Prefix: jdbc:db2 (accept the default value)JTA Enabled: false (accept the default value)

DB2 version 6.1 and higher support Java transaction services. To use Java transactionservices, the setting for ‘JTA Enabled’ would be ‘true’. If ‘JTA Enabled’ is set to ‘true’,then the ‘URL prefix’ must be changed to jdbc:jta:db2.

__2. After the values have been entered, click OK in the properties dialog. As the request isbeing processed, messages indicating the progress will be displayed in the consolemessages section. On completion, a confirmation dialog will appear. You can nowswitch to Topology view and see that an entry for DB2Driver listed under theWebSphere Administrative Domain tree. Select the DB2Driver and the propertiespage will be displayed in the content pane. Return to the Type view to define theDataSource.

__3. Right click the DataSources folder, then click Create. In the properties dialog, enter thefollowing values:

Note: The database specified in the database name has already been created for you.For the Database Name please refer to the separate sheet handed out at the beginningof class.

Data Source Name: big3db2Database Name: <instance_name>DB2Driver: DB2Driver

Note: To keep this configuration simple, you will be using the same database for boththe WebSphere repository and the application data. In a “live” environment, this is notthe recommended configuration.



The settings under the Advanced tab are optional. These are used for configuring theconnection pool.

It is important to know that the database has to be created and must exist before anapplication can be deployed. Later in this lab you will come across a bean configurationoption that can be set to allow the administrative server to create the tables automatically.However, the database creation has to be done separately.

__4. Click OK and wait for the confirmation dialog to appear. Again, you can check theTopology view for the big3db2 datasource entry. Select Default DataSource to view theproperties sheet.

__5. The next step is to specify the location of the driver code. In a terminal window, locatethe DB2 JDBC driver. Execute the command:

find / -name admin.configfrom a terminal. Go to that that directory and use a text editor to open the admin.configfile. Search for db2java.zip. Make note of the file path specified in front of the filename, you will need it for the next step. You are interested in the Java1.2-specificversion of db2java.zip. In a default configuration, this will fall under the home directoryof the DB2 instance.

__6. From the Topology view, locate DB2Driver (created in step 2).

— Right click the driver, then select Install. This will display an Install Driver dialog(shown below).

— Select your local machine as the node on which to install the driver. This will enablethe Browse button. You can now browse to the db2java.zip file you located in theprevious step.

— Select the file and click Open. The path name appears in the Jar file field. — To complete the configuration, click Install. A confirmation dialog will appear

indicating that the administrative server is now aware of the location of the JDBC



driver code.

The configuration for database support is now complete. In the next exercise you willcreate the EJB Container that will make use of this datasource.

Part Three: Configuring a Web Application and other resources

You will now configure the Big3 application code, including the HTML pages, servlet,and Enterprise Java Beans, using the Administrative Console. First, you will create anapplication server to host the EJB container and the servlet engine. The Big3 EJBs willbe deployed into the EJB container, and the servlets and HTML pages will be deployedin a web application within the servlet engine.

The Administrative Console provides wizards that allow for the configuration andcustomization of all these objects. The wizards are located on the toolbar. Click themagic wand icon to display the list of task wizards. Alternatively, you can click theConsole menu and select Tasks from the drop-down menu.

__1. To create an application, select ‘Create Application Server’ from the list of tasks. Anexplanation of the task will appear in the content pane.



__2. When the wizard starts, select the Enterprise Beans and Web Applicationscheckboxes and click Next.

If you do not select any choices, an application server without any resources will becreated. These resources can be added later. However, we will add them now. SelectingEnterprise Beans allows for the configuration of a container and enterprise beans. TheWeb Applications option allows for the configuration of a servlet engine, a Webapplication and a servlet.

__3. The next display is a notebook to configure the properties of application server. Underthe General view these settings are grouped under the title of EJBServer Properties.Type the following values:

Application Server Name: Big3ServerStandard output: <as_root>/logs/Big3Server.outStandard error: <as_root>/logs/Big3Server.err

Note: The Command Line Arguments field can remain blank. In the past, youentered the maximum heap size for the application server’s Java process. The defaultsetting allows the JVM to grow to approximately half your real memory. You may needto experiment with appropriate settings for this parameter as load on your applicationincreases. The larger this value is, the more memory your application will be allowed toconsume. However, if the heap size is set too small, the performance of yourapplication will suffer. When determining what heap size works best for you, 128 MBis a good place to start for many applications under load.



Accept the defaults for the Command line arguments, Environment, and WorkingDirectory and Standard input fields.

__4. Click Next.

__5. The next display lets you specify whether the application should be started automaticallyafter the configuration is complete. Select Do not start the server automatically aftercreating it and click Next.

__6. Specify the node on which the application server will reside. In this case there should beonly one entry with the name of your local machine listed. Select it and click Next.

__7. You are now ready to deploy the enterprise beans for the Big3Server to manage. ClickBrowse. The browse dialog displays the <as_root>/deployedEJBs directory. Select thebig3deployed.jar file. If you double click instead of selecting the jar file, the contents ofthe jar file will be displayed. If this happens, back out one level to the jar file. ClickSelect. Select Yes to confirm you want to deploy all of the EJBs and deploy the JARfile.



You will now see three beans (ProcessClaim, Process, and Claim) listed in theEnterprise Bean List.

__8. Click Next. This will bring up the page to configure a container. Type the followingvalues:

On the General Tab:

EJBContainer Name: Big3EJBContainer

On the DataSource Tab, click the Change button and select the big3db2 datasource.Click Ok. Fill in the following values:

Userid: db2inst1Password: ibmdb2

.



The settings applied to the container are inherited by the beans contained within it. Youcould have specified these settings to each entity bean individually. However, if allbeans use the same datasource then it is convenient to use this approach. In a laterportion of this lab, the datasource associated with the container will be changed to usean Oracle database.

__9. Click Next to select a virtual host. This panel allows you to use an existing virtual hostor create a new one. Select default_host.

__10. Click Next to configure a servlet engine. On this panel you can specify a name for theservlet engine. Enter the following for the servlet engine name: Big3ServletEngine.

__11. Click Next to specify the Web Application properties. Use the following settings:

Web Application Name: Big3WebAppVirtual Host: default_host (accept default virtual host)Web Application Web Path: /Big3

.

__12. Click the Advanced tab and make note of the Document Root path. You will need thislater in the lab.



__13. Click Next to configure the default servlets for the Web Application. Make sure theEnable File Servlet checkbox and the Enable JSP 1.0 radio button are selected. ClickFinish.

When the task is complete, a message will be displayed stating the CreateServer taskcompleted successfully. Click OK. You can now take a look at the Topology view andsee the entry for the Big3Server. To view the Big3Server entry, expand the node.Expand the entry to see the subcomponents that were just configured for it.

__14. View the Datasource tab for the EJBs in the Big3EJBContainer. Note that on the twoentity beans the "Create table" box is checked. This means that when the beans arestarted, they will go out to the database specified by their datasource (in this case thedatasource inherited from the container) and create the correctly configured databasetables.

NOTE: If you used the deployable JAR file you created using jetace in the earlier lab,these tables would be created with a schema of ejb, and would be named<bean_name>beantbl (ejb.policybeantbl, ejb.claimbeantbl). You are using a JAR filecreated using VisualAge for Java. VisualAge for Java creates a schema that isdifferent from the one created by jetace unless you specify the schema mappingbefore you generate the deployed code. In this case, the tables are created with aschema of db1inst1.<bean_name> (db2inst1.Policy and db2inst1.Claim). WebSphere3.x only supports mapping of container-managed EJBs to tables created byWebSphere. If you want to map your EJBs to existing database structures, you needto either use bean-managed persistence, or use VisualAge for Java.

__15. View the deployment descriptor properties for each of the beans by clicking on the editbutton on the general tab of the bean property sheet. Each bean has a Remote and aHome interface, and an enterprise bean class that is the bean containing the businesslogic.



Note that if you are viewing one of the entity beans (Policy or Claim), the Entity tab isavailable. This tab displays the name of the primary key class and thecontainer-managed fields. If you are viewing the session bean (ProcessClaim), thesession tab will be available. This tab displays the Session state and session timeoutvalues.



Part Four: Configuring File Serving Enabler and adding the Servlets

__1. From the Topology view, selectBig3Server-->Big3ServletEngine-->Big3WebApp-->File Serving Enabler. Theproperties for the File Serving Enabler will be displayed in the content pane.

__2. In the Servlet Web Path List, highlight the entry for default_host/Big3 and click Remove.

__3. In the Servlet Web Path List, click Add. .



The Virtual Host field displays default_host. The Servlet Path starts with /Big3. Boththese values are uneditable. However, you can add the names of the HTML pages atthe end of the Servlet Path. The HTML file names are case sensitive. Add the followingfiles one at a time. To do this, enter the file name and click OK. Click Add to enter thenext file name, then click OK. When all the file names have been added, click Apply.

index.htmltop.htmlMenuFrame.htmlnull.htmlProcessClaim.htmlVerifyClaim.htmlverify.html

The final path name should appear as /default_host/Big3/<html file>. Be sure to clickApply before leaving this page or the modifications will be lost. In the next step, theservlet will be added to the Web Application.

Note: You could have just specified *.html instead of specifying each file. This providesfor easier administration, but is less secure. If *.html is specified, you must ensure thatsomeone can not put an unauthorized HTML file in the document root of the application.

__4. From the Wizards menu, select the Add a Servlet wizard. This will display the firstpage of the task.

__5. At the prompt, “Do you want to select an existing Servlet jar file or Directory thatcontains Servlet classes?” select No. Click Next.

__6. This page lets you select an application into which to add the servlet. Expand the tree,until the entry for Big3WebApp appears. Select it and click Next.

__7. This task has a feature that lets you pick out the type of servlet. On this screen select“Create User Defined Servlet” to choose the later configuration option. Click Next.



__8. The physical location of the servlet and the WebSphere alias are specified on thisdisplay. Use the following values:

Servlet Name: ProcessClaimServletServlet Class Name: big3.servlet.ProcessClaimServletClick Add and fill in:Servlet Web Path: servlet/big3.servlet.ProcessClaimServlet

Note: The ProcessClaim.html form's action must match the Servlet Web Path . “default_host/Big3/” is automatically prepended to the Servlet Web Path by the wizard.

__9. Click Finish. Look for the confirmation dialog indicating success. Locate the new entryin the Topology view. Under what WebSphere resource does it appear?

__10. Add another servlet, VerifyClaim, as you did above, using the following values:

Servlet Name: VerifyClaimServletServlet Class Name: big3.servlet.VerifyClaimServletClick Add and fill in:Servlet Web Path: servlet/big3.servlet.VerfiyClaimServlet

Part Five: Placing the files.

Now you must move the servlets and the HTML files into the WebSphere document rootand servlets directories.

__1. Make a directory in <as_root>/hosts/default_host/ called Big3WebApp: mkdir <as_root>/hosts/default_host/Big3WebApp

__2. Make a directory in <as_root>/hosts/default_host/Big3WebApp called web: mkdir <as_root>/hosts/default_host/Big3WebApp/web



__3. Make a directory in <as_root>/hosts/default_host/Big3WebApp called servlets: mkdir <as_root>/hosts/default_host/Big3WebApp/servlets

__4. Copy the HTML files from /usr/big3/html to the web directory you just created: cd <as_root>/hosts/default_host/Big3WebApp/web

cp /usr/big3/html/* .

__5. Copy the servlet jar file from /usr/big3/servlets to the servlets directory you just created cd <as_root>/hosts/default_host/Big3WebApp/servlets

cp /usr/big3/servlets/* .

Part Six: Adding Aliases to the Default_Host

__1. In the Topology view, select default_host.

__2. In the property sheet for the default_host, click the Advanced tab and scroll to the HostAliases list. Add the fully qualified host name for your machine to the list. Click Apply.As you can see, there are entries for localhost, your AIX machine short name, your IPaddress, and now, the fully qualified name. This makes your application moreaccessible, enabling the use of any of these forms of address from the Web browserand Java client applications.

Part Seven: Testing the Big3 Application

__1. From the Topology view, select Big3Server. Click Start in the toolbar (the green arrow)or right click Big3Server and select Start. Wait for the Big3Server and its components tostart. This will be indicated by a confirmation message.

__2. View the datasource tab for the two entity EJBs. Note that the "Create Table" checkboxis no longer checked.

__3. Starting the Big3Server also wrote information to the Big3Server log files in the<as_root>/logs directory. In a terminal window, execute the commands:

more <as_root>/logs/Big3Server.outmore <as_root>/logs/Big3Server.err

Any information written to the stdout or stderr of your application (exceptions, etc.) willbe written to these two files.

__4. Open a new terminal window and type netscape& to start the Netscape browser. Pointthe browser to http://<fully_qualified_machine_name>/Big3/index.html. The main pageof the Big3 Web application will appear.



These static pages are served up by the WebSphere Administrative Server. This showsthat the File Serving Enabler has been configured correctly. Click Submit on the form inthe content pane. This sends the request back to WebSphere, which passes it to theProcessClaimServlet. The servlet invokes the enterprise beans to complete theprocessing. The beans use the database connections specified for theBig3EJBContainer and store information in the database. When all the transactions arecompleted successfully, a message showing the response time is sent back to thebrowser. In the event of failure, an error message indicating the failing component isreturned.

If you have difficulty getting the index.html file to appear, make sure<fully_qualified_machine_name> has been correctly configured in the default_host.

__5. As a result of the test, new records were created by the entity beans. The records are inthe db2inst1.Policy and db2inst1.Claim tables in the database specified by thedatasource. To view them, execute the following commands:

su - db2inst1 Note: the dash is very important. It ensures the db2inst1 profiledb2 script is run.connect to <database_name> user db2inst1 using ibmdb2select * from db2inst1.Policy

and,

select * from db2inst1.Claimquitexit

__6. To test the EJBs using the Java Client, open an MS DOS window on the Windows NTmachine and change to the C:\big3 directory. Check the GetClientClassPath.bat fileand make sure that the WAS_HOME is set up correctly.

__7. Execute the following command:compile

to compile the Main.java file

__8. Execute the following command:

RunClient <policy_number> <claim_number> <amount_of_claim> <AIX_Machine_name>

to run the Big3Client. Replace the parameters in <> with values.(For example: RunClient 1234 5678 10 XX where XX is your machine name.)

__9. At the completion of the test, check the database for new records.



Part Eight: Modifying Database Support

To provide Oracle database access, you will perform similar configuration steps as before.However the settings will be specific to Oracle.

__1. From the Type view, right-click JDBCDrivers --> Create. This will display theproperties dialog where you will specify information concerning the JDBC Driver.

Enter the following values:Name: OracleDriverClass Name: oracle.jdbc.driver.OracleDriverURL Prefix: jdbc:oracle:thin:<db_host>:1521 (enter your db_host)JTA Enabled: false (accept the default value)

__2. After the values have been entered, click OK in the properties dialog. As the request isbeing processed, messages indicating the progress will be displayed in the consolemessages section.

Upon completion, a confirmation dialog will appear. You can now switch to Topologyview and see an entry, OracleDriver, listed under the WebSphere Administrative Domaintree. Click it and the properties page will be displayed in the content pane. Return backto the Type view to define the DataSource.

__3. Right click the DataSources folder on the Type view. Then click create. In theproperties dialog enter the following values under the General Tab:

DataSource Name: big3oracleDatabase Name: <instance_name>Driver: OracleDriver

The settings under the Advanced tab are optional. These are used for configuring theconnection pool.

Note: Replace <instance_name> with the name of the oracle instance assigned to yourgroup.



__4. Click OK and wait for the confirmation dialog to appear. Again, you can check theTopology view for the big3oracle data source entry.

__5. Locate the oracle JDBC driver. Execute the command:

find / -name classes12.zipfrom a terminal window. Make note of where the file is located, you will need it for thenext step.

__6. From the Topology view, locate the JDBCDriver that was created above (OracleDriver).Right click and then click Install. This will display an Install Driver dialog. Select yourlocal machine as the node on which to install the driver. This will enable the Browsebutton and you can now browse to the classes12.zip file you located in the previousstep. Select the file and click Open. The path name appears in the Jar file field. Tocomplete the configuration, click Install. A confirmation dialog will appear indicating thatthe applications server is now aware of the location of the JDBC driver code.

The configuration for database support is now complete. The datasource is nowavailable to be used by the application to access the Big3 database. In the next part ofthe exercise, you will configure the Big3 EJBs you deployed earlier to use this newdatasource.

Part Nine: Change Container properties to use the Oracle Datasource.

In this step you will configure the Big3EJBContainer to point to the newly created OracleDataSource.

__1. Stop the Big3Server if it is running. This can be accomplished from the Topology view.Select Big3Server, right click, and select Stop.

__2. Expand the Big3Server tree and locate the entry for Big3EJBContainer. The propertiesfor the container will be displayed in the content pane. Click DataSource tab. Thesettings currently indicate big3db2 as the datasource name.

___Change the datasource name to big3oracle by selecting the Change... Button.

___Change the UserID and Password as indicated on the lab cheat sheet.

__3. Click Apply to save the changes. Wait for the confirmation dialog before proceeding.

__4. Restart Big3Server. Your EJBs should now be persisted to the Oracle database.



Part Ten: Troubleshooting Exceptions

__1. Open a browser window (use netscape& from a terminal window). Point the browserto http://<fully_qualified_machine_name>/Big3/index.html

__2. Click Submit to submit the form. The ProcessClaimServlet should load correctly, butthe following exception will be thrown when the entity beans are accessed:

javax.transaction.TransactionRolledbackException: CORBATRANSACTION_ROLLEDBACK 0 No; nested exception is:org.omg.CORBA.TRANSACTION_ROLLEDBACK: minor code: 0 completed: No

WebSphere throws this TransactionRolledbackException when it catches an exceptionfrom the database. The best way to troubleshoot the cause of the exception is to turnon WebSphere tracing to view the exception the database is throwing to WebSphere.

__3. Tracing can be applied for the entire Administrative Server (node), or a specificapplication server. To access the Trace Administration dialog for the Big3Server, rightclick Big3Server and select Trace.

__4. Using this tracing mechanism, trace information will be stored in a ring buffer inmemory. The Ring Buffer Size specifies the size of this buffer in KB. When the buffer isfull, the oldest trace record is discarded to make room for the newest record. Increasethis buffer to 50 KB by entering 50 in the box and clicking the Set Size button.

NOTE: The Console Messages section of your main Administrative Console window willprint the following messages:

Command "setRingSize" running ...Command "setRingSize" completed successfully.

__5. You can trace on a hierarchical list of Java packages (Component) or a logical groupingof Java packages (Group). Tracing a small number packages decreases the amount ofmessaging you receive and reduces the performance hit incurred. However, if yourtrace is too narrow, you may miss important information.

In this lab, you are going to run a Components trace on com.ibm.ejs. Double clickComponents. Click the plus signs in front of com and then ibm.

__6. Select, then right click ejs and select All from the menu. This adds three colored stripesto the box in front of the ejs entry. The blue stripe means tracing is enabled forEntry/Exit, the yellow stripe means tracing is enabled for Event, and the red stripemeans tracing is enabled for Debug. The Components, com, and ibm boxes are turnedfuschia, to signify that some sub-components are being traced.



__7. Click the Set button to activate the Trace.

__8. Return to your browser window. Click the back button to return to the Claim Data form.Click the Submit button to submit the form. The same exception will occur.

__9. Return to the Trace Administration dialog by right clicking Big3Server and selectingTrace.

__10. To dump the ring buffer trace information to a file, type /tmp/deploy.dmp in the DumpFile Name field and click Dump.


Command "dumpRingBuffer" running ...Command "dumpRingBuffer" completed successfully.

__11. View the file you just created. The first several lines give information about the level ofWebSphere you are running. The next several lines give information that is printed tothe ring buffer and stdout when the applicatoin server starts (for example, servletavailable for service, etc.). After those messages, you will begin to see WebSpheretracing messages.

__12. Search for the word, “Exception”. You should find an exception that looks like this:

Portability > translateException: java.sql.SQLException:ORA-00942: table or view does not exist



In the stack trace, you see that the exception occurs during a call toBig3EJB.EJSPolicyHomeBean.findByPrimaryKey. This means that the table the Policybean is configured to access does not exist. When you switched to the Oracledatabase, you did not tell the beans to create their database tables.

__13. Now that you have discovered the problem, you need to turn off tracing. Right clickBig3Server and select Trace. Right click Components and select None. The box infront of Components should return to the gray color.

__14. Click the Set button to deactivate the trace.


Command "setTrace" running ...Command "setTrace" completed successfully.

__15. To correct the problem, stop the Big3Server. Select the Create Table check box on theDataSource tab for both the Policy and the Claim EJBs. Be sure to click Apply beforeyou leave the property sheet for each bean. The beans are located under theBig3EJBContainer entry on the Topology view.

__16. Restart Big3Server and test from Netscape. The request should now completesuccessfully.

NOTE: The trace method you used allows you to turn tracing on and off dynamically for arunning application server or administrative server. If you wish to trace a server from thetime it starts to the time it stops, go to the property sheet for that server and use the TraceSpecification and Trace Output entries.

__17. Now use the JDBC program to verify that the claim you submitted actually inserted datainto the Oracle database tables.

— Edit /usr/big3/chkorcl/chkorcl.java using your favorite text editor or by opening theGUI text editor.

— Locate the getConnection call and change the values for <db_host> and<instance_name> to the values for your group.

— Save chkorcl.java and close the file.

__18. Run the /usr/big3/chkorcl/compile.sh script.

__19. Run the /usr/big3/chkorcl /run.sh script. The contents of the ejb.Policy and ejb.Claimtables will be displayed.



Summary

In this lab you deployed and tested the Big3 application using the Administrative Console. Youalso used the Administrative Console to store EJB data to a DB2 database, then to an Oracledatabase. You tested the configuration and used the Trace facility to determine why youreceived a rollback exception. After successfully configuring the application to use the Oracledatabase, you tested your configuration by viewing the contents of the tables.

END OF EXERCISE



programming model issues - ibm...use bean-managed persistence when container-managed persistence...

Documents