CONFIGURATION AND APPLICATIONS DEPLOYMENT IN WEBSPHERE 6.1

(1)

CONFIGURATION AND

APPLICATIONS

DEPLOYMENT IN

WEBSPHERE 6.1

BUSINESS LOGIC FOR TRANSACTIONAL

EJB ARCHITECTURE JAVA PLATFORM

(2)

Configuration and applications deployment in WebSphere 6.1 / BLT_TREJB2

1 INSTALLING WEBSPHERE 6.1______________________________________________2 2 BEFORE DEPLOYING ________________________________________________________2 2.1 The administration console ______________________________________________3 2.2 Data Source configuration _______________________________________________4 2.3 Triggers configuration ___________________________________________________9 3 APPLICATION DEPLOYMENT ______________________________________________15

(3)

1 INSTALLING WEBSPHERE 6.1

A trial version of WebSphere 6.1 can be downloaded from this site:

http://www.ibm.com/developerworks/downloads/ws/was/index.html

Extract the content of the downloaded file ‘was.cd.6100.trial.base.windows.ia32.zip’ and launch the install program located inside the WAS folder. During the installation process, the program asks for a user name and a password. If this step fails, just uncheck this feature and keep on installing WebSphere 6.1.

2 BEFORE DEPLOYING

WebSphere version 6.1 supports JDK 5.0, but has some constraints, like the use of generics in bean interfaces.

Once the application server is installed, go to the WebSphere 6.1 menu and click the ‘Start the server’ option in order to start the server. After that, the ‘Administrative console’ can be used to manage the application server.

Figure 1 Application menu

NOTE: If the Administrative console does not start correctly, maybe the server has not

been properly initialized. In that case, IBM recommends using the ‘Installation verification’ option in the ‘First Steps’ utility:

(4)

Figure 2 First steps

If the ’Installation verification’ does not fix the problem and the Administrative console does not start up it is recommended to uninstall the application server, remove the WebSphere folder from the installation directory (the uninstall process does not remove this folder itself) and reinstall the application server.

If some of the applications that will be deployed in the application server contain legacy views, two additional libraries have to be copied to the <WebSphereInstallationPath>\AppServer\lib folder. These libraries are the jaxp-ri.jar and jaxp-api.jar, and they are needed to enable the communication between the legacy and the local systems. Without these libraries this kind of applications cannot be executed. The JAXP 1.4 libraries can be freely downloaded from https://jaxp.dev.java.net/

Besides, if the application that will be deployed has been generated with the audit log file generation option, an additional library has to be copied to the <WebSphereInstallationPath>\AppServer\lib folder. This library is the log4j-1.2.15.jar and is needed to create and manage the audit log files. It can be freely downloaded from

http://logging.apache.org/log4j/1.2/download.html

2.1 The administration console

If the initialization of the application server has been successful, the Administrative console appears and asks for the user name and password in order to start the session. This user is used only to manage the Administrative console.

(5)

Figure 3 Authentication

The Administrative console is shown if the user name and password are correct.

Figure 4 Administration console

2.2 Data Source configuration

The applications generated by BLT_TREJB2 (Business logic for transactional EJB architecture Java platform) require two different data sources to achieve a better control of the isolation level in the accesses to the database. One data source is needed for services and another one for queries for each deployed application.

In order to create these data sources a JDBC provider is required, so go to ‘Resources – JDBC – JDBC Providers’. WebSphere has some predefined JDBC providers, but a new one can be created if necessary. In this How-to, the predefined JDBC provider for Microsoft SQLServer is being used as an example.

(6)

Figure 5 JDBC provider creation

Once the JDBC provider has been set, the associated data sources can be created. The data sources configuration page is located under ‘Resources - JDBC - Data sources’.

Figure 6 Data source page

Click the ‘New’ button in order to create a new data source.

Two data sources have to be created, one for services and one for queries. The names given to said data sources, by default, are formed by using the package name of the application to be deployed and the suffix ‘DB_SERVICE’ (data source for services) or ‘DB_QUERY’ (data source for queries):

(7)

ApplicationNameDB_QUERY ApplicationNameDB_SERVICE

In the first step the data source name and the JNDI name are specified and the authentication alias used to connect to the database is selected.

Figure 7 New data source (Step 1)

If there is not an authentication alias, just click the ‘Create a new J2C authentication alias’ link to create a new one by entering the alias and a user id and user password. The user id and password must be those of a user that have sufficient rights to access the targeted database. Please notice that if you have to create a new J2C authentication alias, the wizard to create a new data source will be cancelled and you will have to start again once the new J2C alias has been created.

(8)

Figure 8 New authentication alias

In the second step of the wizard, select the JDBC provider.

Figure 9 New data source (step 2)

In the third and last step, the database information, such as the database name, the database server name and the port, are specified. In this case, the JDBC provider for MS SQLServer is selected.

(9)

Note:

1433 is the port number associated with Microsoft SQLServer databases. Therefore this value depends on the database manager selected.

(10)

2.3 Triggers configuration

In case that an application with triggers is going to be deployed, the creation of a JMS queue is necessary. This is because the information about pending triggers to be executed is managed as messages added to this queue.

In order to get the queue ready, different elements have to be created before deploying. First of all, an ‘Interaction service bus’ is required. To create this element, go to ‘Service integration – Buses’ and click the ‘New’ button.

Introduce the bus name and uncheck the ‘Bus security’ checkbox. Specifying users with permissions to access the bus is not necessary for the deployment of applications with triggers.

(11)

Press ‘Next’ and confirm the creation of the new bus pressing Finish.

Figure 14 Create a new Service Integration Bus (Step 2)

(12)

Next, a queue connection factory is needed. To create one, go to ‘Resources – JMS - Queue connection factories’, click the ‘New’ button and select the ‘Default messaging provider’ option. The queue connection factory has to be associated to a scope, so one has to be selected one before creating the queue connection factory. Selecting the ‘Default messaging provider’ will suffice.

Figure 16 New queue connection factory

The next step is to define the connection factory alias, the JNDI name, the bus and some options in the ‘Advanced administration’ section. This JNDI name has to be formed in the same way that it was specified in the deployment descriptor and in the application code, which is ‘ApplicationName_ConnectionFactory’. The bus is the one created before. In the ‘Advanced administration’ section select the authentication alias in the ‘Component-managed Authentication Alias’ and also in the ‘XA-recovery Authentication alias’ field. Leave the remaining options by default.

(13)

(14)

The JMS queue can be now created. Go to ‘Resources – JMS – Queue’, click the ‘New’ button and choose the ‘Default messaging provider’ option.

In the next page, enter the alias, the JNDI queue name and, in the ‘Connection’ area, select the ‘Bus name’ and ‘Queue name’ from the corresponding combo boxes.

The JMS queue requires the following name: ApplicationName_TriggersMDB

Figure 18 New queue

Once the queue is created an ‘Activation specification’ has to be defined. To do this, go to ‘Resources – JMS – Activation Specifications’ and click in the ‘New’ button selecting the ‘Default messaging provider’ option.

The alias, the JNDI name of the activation specification and the destiny JNDI name, have to be now created. Select the bus from the combo box and leave the remaining options by default.

The activation specification is named like this: ApplicationName_ActivationSpec

(15)

(16)

At this point, all the necessary elements to deploy and use the JMS queue have been defined and are ready to use.

3 APPLICATION DEPLOYMENT

Once the data sources and the JMS queue (if needed) have been created, it is time to deploy the application. To do this, go to ‘Application – Install a new application’.

Figure 20 EAR selection

Select the path to the EAR file in the next screen and click ‘Next’.

In the next page, three steps are shown, but nothing has to be modified since all the information needed is in the specific WebSphere deployment descriptors included in the EAR file.

(17)

Figure 21 Application deployment

When the application is deployed it has to be started it in order to work with it. Go to ‘Applications – Enterprise applications’, select the application and click the start button.

(18)

Figure 22 Enterprise applications

If the start process is successful, the application can be accessed through the port 9080 using the following connection string:

http://localhost:9080/ApplicationNamexml/invxml

NOTE:

CONFIGURATION AND APPLICATIONS DEPLOYMENT IN WEBSPHERE 6.1