Advanced SSL configuration on IBM Http Server – Restrict unused HTTP methods and Verbose HTTP headers

Restricting unused HTTP methods

The HTTP method is supplied in the request line and specifies the operation that the client has requested. Browsers will generally just use two methods to access and interact with web sites; GET for queries that can be safely repeated and POST for operations that may have side effects. This means, we need to disable unused http methods. some of them are:(PUT|DELETE|TRACE|TRACK|COPY|MOVE|LOCK|UNLOCK|PROPFIND|PROPPATCH|SEARCH|MKCOL). Check with the application teams, if they need any of these methods for the application to work, before disabling them.

Testing before limiting http methods:

telnet josephamrithraj.mp 80
Trying xx.xx.xx.xx…
Connected to josephamrithraj.mp.
Escape character is ‘^]’.
OPTIONS / HTTP/1.1
Host: josephamrithraj.mp

HTTP/1.1 200 OK
Date: Thu, 14 Sep 2010 00:11:57 GMT
Server: Apache Web Server
Content-Length: 0
Allow: GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, PATCH, PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, UNLOCK, TRACE

Connection closed by foreign host.

your IBM http servers configuration file [httpd.conf] has 2 sections named main and virtualhost sections. you need to add the following code at both the places. I am explaining this task using mod_rewrite module. So, first make sure that… mod_rewrite is enabled. then, add the following lines to your http.conf files main and virtualhost sections.

RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^(PUT|DELETE|TRACE|TRACK|COPY|MOVE|LOCK|UNLOCK|PROPFIND|PROPPATCH|SEARCH|MKCOL)
RewriteRule .* – [F]

Restart the web server after adding the above lines.


Now, when someone tried to use one of these http methods, they will get forbidden response since we specified [F] in the rewrite rule.

Testing after adding and restarting web server

telnet josephamrithraj.mp 80
Trying xx.xx.xx.xx...
Connected to josephamrithraj.mp.
Escape character is '^]'.
OPTIONS / HTTP/1.1
Host: josephamrithraj.mp

HTTP/1.1 200 OK
Date: Thu, 14 Sep 2010 00:15:44 GMT
Server: Apache Web Server
Content-Length: 0
Allow: GET, POST
Connection closed by foreign host.
Testing TRACE methods

telnet josephamrithraj.mp 80
Trying xx.xx.xx.xx...
Connected josephamrithraj.mp
Escape character is '^]'.
TRACE / HTTP/1.0
Host: josephamrithraj.mp
testing... <- ENTER twice HTTP/1.1 403 Forbidden Date: Thu, 14 Sep 2010 00:18:31 GMT Server: Apache Web Server Content-Length: 320 Connection: close Content-Type: text/html; charset=iso-8859-1

Forbidden

You don't have permission to access / on this server.

Connection closed by foreign host.
Disable verbose HTTP headers:


you might have seen this … when the web server [apache or ibm http server] throws errors page, sometimes it might show the information related to its version, build, modules etc. This is a security issue since you are giving away the details about your web server. for example, take a look at this:

Server: Apache/2.0.53 (Ubuntu) PHP/4.3.10-10ubuntu4 Server at xx.xx.xx.xx Port 80
The line in the server header expose important version and variant information about the Linux operating system and Apache software used on the machine, indirectly expose the possible security holes that are existed to the hackers, or at least make malicious attackers easier to identify your system for available attack points.
To ensure that the Apache HTTP web server does not broadcast this message to the whole world publicly and fix possible security issue, modify these two directives ServerTokes and ServerSignature in httpd.conf configuration file.

ServerTokens

This directive configures what you return as the Server HTTP response Header. The built-in default is ‘Full’ which sends information about the OS-type and compiled in modules. The recommended value is ‘Prod’ which sends the least information.

Options: Full | OS | Minor | Minimal | Major | Prod

“ServerTokens Prod”

This configures Apache to return only Apache as product in the server response header on very page request, suppressing OS, major and minor version info.

ServerSignature

This directive lets you add a line containing the server version and virtual host name to server-generated pages. It is recommended to set it to OFF and Set to "EMail" to also include a mailto: link to the ServerAdmin.

Options: On | Off | EMail

“ServerSignature Off”

This instructs Apache not to display a trailing footer line under server-generated documents, which displays server version number, ServerName of the serving virtual host, email setting etc..


Courtesy:http://josephamrithraj.wordpress.com/2010/09/16/advanced-ssl-configuration-on-ibm-http-server-restrict-unused-http-methods-and-verbose-http-headers/

Advanced SSL configuration on IBM Http Server – Client Authentication and Ciphers

The Advanced SSL Configuration settings are

Client Authentication
Setting Ciphers
SSL for multiple IP virtual Hosts
Client Authentication:

If you enable client authentication, the server validates clients by checking for trusted certificate authority, Known as CA root certificates in the local key database. To enable client authentication, you need to use SSLClientAuth directive. The options to use with this stanza are:

None – The server requests no client certificate from the client.
Optional – The server requests, but does not require, a client certificate. If presented, the client certificate must prove valid.
Required – The server requires a valid certificate from all clients and returns a 403 status code if no certificate is present.
Required_reset – The server requires a valid certificate from all clients, and if no certificate is available, the server sends an SSL alert to the client. This enables the client to understand that the SSL failure is client-certificate related, and will cause browsers to re-prompt for client certificate information on subsequent access. make sure you have GSKit version 7.0.4.19 or later when you choose this option.
For example, If i want all the clients to be authenticated, then i need to add the following stanza
SSLClientAuth required

Ciphers

We set the cipher specification to use during secure transactions. The specified cipher specifications validate against the level of the Global Security Kit (GSK) toolkit that is installed on your system. Invalid cipher specifications cause an error to log in the error log. If the client issuing the request does not support the ciphers specified, the request fails and the connection closes to the client. IBM HTTP Server has a built-in list of cipher specifications to use for communicating with clients over Secure Sockets Layer (SSL). The actual cipher specification that is used for a particular client connection is selected from those which are supported by both IBM HTTP Server and the client.

Some cipher specifications provide a weaker level of security than others, and might need to be avoided for security reasons. Some of the stronger cipher specifications are more computationally intensive than weaker cipher specifications and might be avoided if required for performance reasons. When an SSL connection is established, the client (web browser) and the web server negotiate the cipher to use for the connection. The web server has an ordered list of ciphers, and the first cipher in that list which is supported by the client will be selected.

IBM HTTP Server supports the following SSL ciphers: SSLv3 and TLS and SSLv2

IBM recommends the following setting, keeping in mind both strong security and performance

## SSLv3 128 bit Ciphers
SSLCipherSpec SSL_RSA_WITH_RC4_128_MD5
SSLCipherSpec SSL_RSA_WITH_RC4_128_SHA

## FIPS approved SSLV3 and TLSv1 128 bit AES Cipher
SSLCipherSpec TLS_RSA_WITH_AES_128_CBC_SHA

## FIPS approved SSLV3 and TLSv1 256 bit AES Cipher
SSLCipherSpec TLS_RSA_WITH_AES_256_CBC_SHA

## Triple DES 168 bit Ciphers
## These can still be used, but only if the client does
## not support any of the ciphers listed above.
SSLCipherSpec SSL_RSA_WITH_3DES_EDE_CBC_SHA

## The following block enables SSLv2. Excluding it in the presence of
## the SSLv3 configuration above disables SSLv2 support.

## Uncomment to enable SSLv2 (with 128 bit Ciphers)
#SSLCipherSpec SSL_RC4_128_WITH_MD5
#SSLCipherSpec SSL_RC4_128_WITH_SHA
#SSLCipherSpec SSL_DES_192_EDE3_CBC_WITH_MD5
View the Ciphers which the server uses for Secure transactions

Set the LogLevel to info in the configuration file. Look in the error log for messages in this format: TimeStamp info_message mod_ibm_ssl: Using Version 2/3 Cipher: longname|shortname. The order that the cipher specifications are displayed in the error log from top to bottom represents the attempted order of the cipher specifications.

View the Ciphers were used for negotiating a connection

You can use the following LogFormat directive to view and log the SSL cipher negotiated for each connection:

LogFormat “%h %l %u %t \”%r\” %>s %b \”SSL=%{HTTPS}e\” \”%{HTTPS_CIPHER}e\” \”%{HTTPS_KEYSIZE}e\” \”%{HTTPS_SECRETKEYSIZE}e\”" ssl_common

CustomLog logs/ssl_cipher.log ssl_common

This logformat will produce an output to the ssl_cipher.log that looks something like this:

127.0.0.1 – - [01/Sep/2010:00:02:05 -0800] “GET / HTTP/1.1″ 200 1582 “SSL=ON” “SSL_RSA_WITH_RC4_128_MD5″ “128″ “128″

SSL for multiple IP virtual hosts

When you do not define an SSL directive on a virtual host, the server uses the directive default. You can define different (SSL) options for various virtual hosts. To enable SSL:

Specify the SSLEnable directive on the virtual host stanza in the configuration file, to enable SSL for a virtual host.
Specify a Keyfile directive and
Any SSL directives you want enabled for that particular virtual host.
Restart the server.
With all the above security options enabled, your virtual host may look like this:



SSLEnable

Keyfile keyfile.kdb

SSLCientAuth required

## SSLv3 128 bit Ciphers

SSLCipherSpec SSL_RSA_WITH_RC4_128_MD5

SSLCipherSpec SSL_RSA_WITH_RC4_128_SHA

## FIPS approved SSLV3 and TLSv1 128 bit AES Cipher

SSLCipherSpec TLS_RSA_WITH_AES_128_CBC_SHA

## FIPS approved SSLV3 and TLSv1 256 bit AES Cipher

SSLCipherSpec TLS_RSA_WITH_AES_256_CBC_SHA

## Triple DES 168 bit Ciphers

## These can still be used, but only if the client does not support any of the ciphers listed above.

SSLCipherSpec SSL_RSA_WITH_3DES_EDE_CBC_SHA

## The following block enables SSLv2.
## Excluding it in the presence of the SSLv3 configuration above disables SSLv2 support.

## Uncomment to enable SSLv2 (with 128 bit Ciphers)

#SSLCipherSpec SSL_RC4_128_WITH_MD5

#SSLCipherSpec SSL_RC4_128_WITH_SHA

#SSLCipherSpec SSL_DES_192_EDE3_CBC_WITH_MD5



Courtesy:http://josephamrithraj.wordpress.com/2010/09/04/advanced-ssl-configuration-on-ibm-http-server-client-authentication-and-ciphers/

How to collect performance data on Linux

Collect the following information when high CPU consumption is with IBM Java process:
Enable garbage collection trace to see whether Java garbage collection is thrashing if possible. If you want to enable Java garbage collection trace on IBM WebSphere Application Server, please refer to the following document: Enabling verbose garbage collection (verbosegc) in WebSphere application Server


Run the following command:

top -d delaytime -c -b > top.log

Where delaytime is the number of seconds to delay. This must be 60 seconds or greater, depending on how soon the failure is expected.


Create a script file, vmstat.sh with the following content:

#vmstat.sh
#output file name
VMSTAT_LOG=$1
LIMIT=288
#sleep for 5 miniutes
SLEEP_TIME=300
while true
do
i=0
echo >$VMSTAT_LOG
while [ $i -le "$LIMIT" ];
do
date >> $VMSTAT_LOG;
vmstat 5 12 >> $VMSTAT_LOG;
i=`expr $i + 1`;
sleep $SLEEP_TIME;
done
done

Create a script, ps.sh with the following content:

#ps.sh
#output file name
PS_LOG=$1
LIMIT=288
#sleep for 5 miniutes
SLEEP_TIME=300
while true
do
i=0
echo >$PS_LOG
while [ $i -le "$LIMIT" ];
do
date >> $PS_LOG;
ps -eLf >> $PS_LOG;
i=`expr $i + 1`;
sleep $SLEEP_TIME;
done
done

Run the scripts:

./ps.sh ps_eLf.log
./vmstat.sh vmstat.log

Notes: . The scripts ps.sh and vmstat.sh, as provided, roll over every 24 hours. . You might need to modify the scripts to meet your needs. . The preceding scripts will run forever. After the error condition is reached, you will have to terminate them.


When high CPU consumption occurs, collect the following logs:

netstat -an > netstat1.out


If the Web server is remote, run the following on the Web server system:

netstat -an > netstatwebserver1.out


Run the following:

kill -3 [PID_of_problem_JVM]


The kill -3 commands create javacore*.txt files

Note: If you are not able to determine which JVM process is experiencing the high CPU usage then you should issue the kill -3 PID for each of the JVM processes.



Wait two minutes.


Run the following:

kill -3 [PID_of_problem_JVM]


Wait two minutes.


Run the following:

kill -3 [PID_of_problem_JVM]


Wait two minutes.


Run the following:

netstat -an > netstat2.out



If the Web server is remote, run the following on the Web server system:

netstat -an > netstatwebserver2.out



If you are unable to generate javacore files, then perform the following:

kill -11 [PID_of_problem_JVM]

WARNING: kill -11 will terminate the JVM process, produce a core file, and possibly a javacore.


Review all output files and collect the following files for IBM Performance Analysis Tool for Java for Linux


ps_eLf.log
javacore*.txt files

Courtesy:http://wasissues.blogspot.com/

Migrating from Websphere 6.0 to Websphere 7.0

The application I manage at work is a client/server application written entirely in java. My company for years has been an IBM shop, so we have a large Websphere presence which is where the server is deployed. The application had been running on Websphere 5.1 for a few years and was fairly recently migrated to Websphere 6.0 to remain on a supported version of Websphere. Because the end of life for Websphere 6.0 is September 2010, we’re starting to plan for another upgrade now (we have major releases in January and June, so we’re targeting the June ’10 release for the upgrade). Websphere 6.1, if IBM holds to it’s pattern of every 2 years or so will remain supported until September 2012, however there’s no current end of life date documented yet (link). To get the longest life possible, I’m looking at Websphere 7.0 as the target platform for our June ’10 upgrade.

We have RAD 7.5 in house and a couple members of my team have installed it. I’ve been working on getting a local WAS 7.0 server up and running and getting our app deployed on it. There are some major differences between Websphere 5.1/6.0 and 7.0. I won’t go into details as those are readily available on IBM’s website, but would like to share some of my observations and pain so far.

Application Background: The server side of our application is effectively broken down into 2 pieces. One component is what we call a provision server that is essentially a cache of configuration data read from DB2. This configuration information contains rules which drive how the second component operates. The second component is the main workhorse app which receives a request, and creates a response based on configuration data retrieved from the provision server (if necessary) and data retrieved from any number of other applications we interface with. We have 2 provision server jvms for load balancing and fail over and roughly 20 app engine jvms spread across 2 data centers (the app engine hosts roughly 3500 end users and we target 200 users per jvm…roughly).

Unsolved Problem 1 – Remote EJB calls across separate local jvm/profiles doesn’t work: Now that you have a high level view of our applications architecture, here’s my first dilema which I haven’t found a solution to. Websphere now has the concept of profiles. Basically a profile equates to a jvm instance. It’s a little more than that, but that’s a good enough understanding for now. So if you want 2 distinct/separate JVMs configured differently, you would need to create 2 profiles and create servers associated with each profile. In all our lifecycles, we have distinct jvms setup for provision and app engine – we don’t cluster the app engine with the provision server because we want our dev/test lifecycles to mirror production, and production is separate because we don’t want a 1:1 correlation of provision server to app engine as the provision server is memory intensive and 2 jvms can handle the entire app engine load very effectively. So I want to replicate that with my RAD 7.5 setup – 1 app engine jvm and 1 provision server jvm running locally within RAD 7.5. That requires 2 separate profiles to be created, then a server defined and associated for each one. No problem. Where I run into problems is at runtime. The app engine makes remote (cross-jvm) EJB calls to the provision server. That requires a JNDI lookup of an EJB remote home object. For some reason, jvm 1 cannot see any JNDI objects that are stored in jvm 2. When I do an initial context and dump out the contents, all I ever get are the local JVM’s name server items. But if I point the local server at one of our test lifecycle provision servers, it sees those just fine. I have no idea why 1 local jvm can’t access another local jvm’s name server. I’m not sure if it’s because of the base version of Websphere that’s running, or some other limitation of the development environment, but that is one hurdle I can’t get over. So my workaround is to just deploy the provision server and app engine in the same jvm as local ejb calls work just fine.

Solved Problem 2 – creating a secure socket for an outbound ssl SOAP request: The app engine is a portal of sorts. It will call any number of external systems to retrieve data and aggregate that data as needed based on the request. There are several system we currently interface and several protocols we use to do so…SOAP over SSL, EJB, JDBD for example. We use apache soap (old, but still works) to call several external systems, one of which is the main system we interface with. In Websphere 5.1 and 6.0, we set our own JKS truststore for the request using the javax.net.ssl.truststore property. This truststore contains the SSL certificates of our target URL. It just worked. Now we move to Websphere 7.0 and the same requests which work in a local WAS 6.o server no longer work. After much digging and reading of documentation, it turns out WAS 6.1 (and 7.0) changed how SSL security was handled. Long story short, when WAS sees a secure socket being created, it assumes responsibility for securing that connection (Big Brother?) instead of letting you do your own thing. Now, there are ways around it, but the point is it is NOT backwards compatible. The quick fix for this was to put the SSL certs in Websphere’s default truststore (go to the admin console, under security and then ssl configuration and you can find a whole bunch of related config). There are several articles on this and I highly recommend reading the Websphere Application Server V7.0 Security Guide for background on this. It is extremely helpful.

More Here

Courtesy:http://bairdblog.wordpress.com/

Multiple webservice implementation classes available at the same time under WAS7

If you want to experiment with webservices by providing several alternative implementations of the same webservice (represented by the element), each having its own URL, and you’re using Websphere 7 and JAX-WS, then:

1. For each alternative implementation, add with a unique name under the element in the WSDL file. Beware: This is essential to enable multiple implementations.
2. For each alternative implementation, define a servlet and servlet mapping in web.xml like this:
view source
print?
1
2 $IMPLEMENTATION_CLASS_NAME$
3 $IMPLEMENTATION_CLASS_NAME$
4 1
5
6
7 $IMPLEMENTATION_CLASS_NAME$
8 /$DESIRED_UNIQUE_URL$
9
3. Create the implementations – likely as POJOs denoted with the @WebService annotation – and set the corresponding portName for each of them (@WebService(portName=””, …))
4. Deploy and use

1. Define a unique wsdl:port for each implementation

As mentioned, it’s necessary to define a unique wsdl:port for each implementation.

We define two ports, LearningActivityPort1 and LearningActivityPort2, using the same port type (i.e. the same transport protocol etc.).

LearningActivity.wsdl:
view source
print?
01
02
03 ...
04 ...
05 ...
06 ...
07
08
09
10
11
12
13
14
15
2. Define a servlet and servlet mapping for each implementation

Next we need to declare each of the webservice implementation classes as a servlet and define a servlet mapping to assign a unique URL to that implementation as described in WAS help:
web.xml:
view source
print?
01
02
05 pokusWeb4was7
06
07
08 LearningActivityHttpBindingImpl
09 example.LearningActivityHttpBindingImpl
10 1
11
12
13 LearningActivityHttpBindingImpl
14 /LearningActivityJaxbService
15
16
17
18 LearningActivityRawXmlServiceImpl
19 example.LearningActivityRawXmlServiceImpl
20 1
21
22
23 LearningActivityRawXmlServiceImpl
24 /LearningActivityRawXmlService
25
26
27 ...
28

When deployed, the two implementation will be thus available under http://localhost:9080/pokusWeb4was7/LearningActivityHttpService and http://localhost:9080/pokusWeb4was7/LearningActivityRawXmlService.
3. Create each implementation linking it to its port name

Finally we write the two implementation, each being assigned to a different port name:
example.LearningActivityHttpBindingImpl:
view source
print?
1 @javax.jws.WebService (serviceName="LearningActivityHttpService", portName="LearningActivityPort1")
2 public class LearningActivityHttpBindingImpl{
3
4 public TransactionResponseMessage updateLearningActivity(LearningActivityMessage learningActivityMsg) {
5 //...
6 return response;
7 }
8 }

example.LearningActivityRawXmlServiceImpl:
view source
print?
1 @javax.jws.WebService (serviceName="LearningActivityHttpService", portName="LearningActivityPort2")
2 public class LearningActivityRawXmlServiceImpl{
3
4 public TransactionResponseMessage updateLearningActivity(LearningActivityMessage learningActivityMsg) {
5 //...
6 return response;
7 }
8 }
Closing notes

Notice that with JAX-WS

* You don’t need webservice.xml – all the necessary information is (may be) provided via annotations
* You don’t need to declare the web services in web.xml unless you need some special configuration (as we do here)

More Here

Courtesy:http://theholyjava.wordpress.com/2010/12/29/tip-multiple-webservice-implementation-classes-available-at-the-same-time-under-was7/

Using Spring and Hibernate with WebSphere Application Server

Summary: If you’re considering using Spring or Hibernate with IBM® WebSphere® Application Server, this article explains how to configure these frameworks for various scenarios with WebSphere Application Server. This article is not an exhaustive review of either framework, but a critical reference to help you successfully implement such scenarios. (Updated with new security information.) This content is part of the IBM

Introduction

The Spring Framework, commonly referred to as Spring, is an open source project that aims to make the J2EE™ environment more accessible. Spring provides a framework for simple Java™ objects that enables them to make use of the J2EE container via wrapper classes and XML configuration. Spring’s objective is to deliver significant benefits to projects by increasing development productivity and runtime performance, while also improving test coverage and application quality.

Hibernate is an open source persistence and query framework that provides object-relational mapping of POJOs (Plain Old Java Objects) to relational database tables, as well as data query and retrieval capabilities.

While many organisations are interested in discovering what benefits they can obtain from using these frameworks, IBM wants customers who do use them to know that they can do so with WebSphere Application Server in a robust and reliable way. This article describes how these frameworks can be used with WebSphere Application Server, and explains best practices for a variety of use cases so that you can get started with Spring or Hibernate as quickly as possible.

Using Spring

Spring is generally described as a lightweight container environment, though it is probably 

more proper to describe it as a framework for simplifying development. The Spring Framework was developed by Interface21, based on publications by Rod Johnson on the dependency injection design pattern. Spring can be used either in standalone applications or with application servers. Its main concept is the use of dependency injection and aspect-oriented programming to simplify and smooth the transitions from development to testing to production.

One of the most often used scenarios involving Spring is to configure and drive business logic using simple Java bean classes. The Spring documentation should provide enough information to build an application using Spring beans; there is nothing WebSphere-specific about this. The following sections describe some of the usage scenarios for using Spring on WebSphere Application Server. Spring applications that are developed following the advice in this article should execute within a WebSphere Application Server or WebSphere Application Server Network Deployment environment with no difficulties.

Except where explicitly stated, the information presented here pertains to Versions 6.0.2.x, 6.1.x, and 7.0.x of WebSphere Application Server on all platforms.

Presentation tier considerations

This section describes considerations relating to the use of Spring in the Web-based presentation tier.

* Web MVC frameworks

Spring’s Web MVC framework is an alternative to other frameworks that have been around for some time. Web MVC frameworks delivered, used, and supported directly by WebSphere Application Server include JavaServer Faces (JSF) and Struts. Spring documentation describes how to integrate Spring with these Web frameworks. Use of any of these MVC is supported by WebSphere Application Server, although IBM will only provide product support for the frameworks shipped with WebSphere Application Server.

* Portlet MVC framework

Spring also provides a Portlet MVC framework (which mirrors the Spring Web MVC framework) and runs in both the WebSphere Portal V6.0 and the WebSphere Application Server V6.1 portlet containers. (See Spring Portlet MVC for an example set of Spring portlets.) Running portlets in the WebSphere Application Server V6.1 portlet container requires that an additional Web application be created to define the layout and aggregation of the portlets. Information on how to use the portlet aggregator tag library can be found in the WebSphere Application Server Information Center and in the article Introducing the portlet container. Using JSF in combination with portlets is a common practice for rendering. For information on how Spring, Hibernate, JSF, and WebSphere Portal can be combined together, see Configuring Hibernate, Spring, Portlets, and OpenInSessionViewFilter with IBM WebSphere Portal.

Data access considerations

This section describes considerations relating to the configuration of Spring beans that access data within a transaction.

The Spring framework essentially wraps Spring beans with a container-management layer that, in a J2EE environment, delegates to the underlying J2EE runtime. Following are descriptions of how Spring beans should be configured so that the Spring Framework properly delegates to (and integrates with) the WebSphere Application Server runtime.

* Accessing data sources configured in WebSphere Application Server

WebSphere Application Server manages the resources used within the application server execution environment. Spring applications that want to access resources, such as JDBC data sources, should utilize WebSphere-managed resources. To do this:

1. During development, the WAR module should be configured with a resource reference. For example:

jdbc/springdb
javax.sql.DataSource
Container
Shareable

2. For EJB JAR files, the same resource-ref should be declared in each EJB that needs to access the data source.

3. A data source proxy bean would then be declared within the Spring application configuration, which references a WebSphere-managed resource provider:

Accessing the data source through this proxy bean will cause the data source to be looked up using the module’s configured references, and hence be properly managed by WebSphere Application Server. Note that the jndiName property value matches the pattern java:comp/env/ concatenated with the res-ref-name declared in the resource-ref.

Alternatively, from Spring 2.5 onwards, this can be done using the approach. Notice how the jndiName property matches the actual value of the res-ref name declared in the resource-ref together with the resource-ref=”true” property:



4. The data source proxy bean may then be used by the Spring application as appropriate.
5. When the application is deployed to a WebSphere Application Server, a resource provider and resource data source must be configured in the normal fashion for use by the Spring application resource reference. The resource reference declared within the module’s deployment descriptor will be bound to the application server’s configured data source during deployment.
* Using JDBC native connections

Spring provides a mechanism for accessing native connections when various JDBC operations require interacting with the native JDBC resource. The Spring JdbcTemplate classes utilize this capability when a NativeJdbcExtractor class has been set on the JdbcTemplate class. Once a NativeJdbcExtractor class has been set, Spring always drills down to the native JDBC connection when used with WebSphere Application Server. This bypasses the following WebSphere quality of service functionality and benefits:
o Connection handle tracking and reassociation
o Connection sharing
o Involvement in transactions
o Connection pool management.

Another problem with this is the WebSphereNativeJdbcExtractor class depends on internal WebSphere adapter classes. These internal classes may differ by WebSphere Application Server version and may change in the future, thereby breaking applications that depend on this functionality.

Use of NativeJdbcExtractor class implementations (for example, WebSphereNativeJdbcExtractor) are not supported on WebSphere Application Server and you should avoid scenarios that require it. The alternative is to use the WebSphere Application Server WSCallHelper class to access non-standard vendor extensions for data sources.
* Using transactions with Spring

WebSphere Application Server provides a robust and scalable environment for transaction processing and for managing connections to resource providers. Connections to JDBC, JMS, and Java Connector resource adapters are managed by WebSphere Application Server regardless of whether or not a global transaction is being used; even in the absence of a global transaction there is always a runtime context within which all resource-provider connections are accessed. WebSphere Application Server refers to this runtime context as a local transaction containment (LTC) scope; there is always an LTC in the absence of a global transaction, and resource access is always managed by the runtime in the presence of either of a global transaction or an LTC. To ensure the integrity of transaction context management (and hence the proper management of transactional resources) WebSphere Application Server does not expose the javax.transaction.TransactionManager interface to applications or application frameworks deployed into WebSphere Application Server.

There are a number of ways to drive resource updates under transactional control in Spring, including both programmatic and declarative forms. The declarative forms have both Java annotation and XML descriptor forms. If you use Spring 2.5 with WebSphere Application Server V6.0.2.19 or V6.1.0.9 or later, you can take advantage of full support for Spring’s declarative transaction model. Spring 2.5 has a new PlatformTransactionManager class for WebSphere Application Server, called WebSphereUowTransactionManager, which takes advantage of WebSphere Application Server’s supported UOWManager interface for transaction context management. Managing transaction demarcation through WebSphere Application Server’s UOWManager class ensures that an appropriate global transaction or LTC context is always available when accessing a resource provider. However, earlier versions of Spring used internal WebSphere interfaces that compromised the ability of the Web and EJB containers to manage resources and are unsupported for application use. This could leave the container in an unknown state, possibly causing data corruption.

Declarative transaction demarcation in Spring 2.5 or later are supported in WebSphere Application Server using the following declaration for the WebSphere transaction support:



A Spring bean referencing this declaration would then use standard Spring dependency injection to use the transaction support, for example:





...



PROPAGATION_REQUIRED



Alternatively, from Spring 2.5 onwards, Spring’s AspectJ support can be utilised. In the following example, can be applied to various parts of the application. This indicates that all methods starting with “get” are PROPAGATION_REQUIRED and all methods starting with “set” are PROPAGATION_REQUIRES_NEW. All other methods use the default transaction settings.









The tag applies those settings to any executed operation defined within the class MyService.






Another alternative mechanism for declaring transaction settings is to use the Spring annotation-based transaction support. This requires the use of Java 5+, and therefore cannot be used with WebSphere Application Server V6.0.2.x.

Add the following to the Spring.xml configuration:



Any methods that require transactional attributes should then be marked with the @Transactional annotation:

@Transactional(readOnly = true)
public String getUserName()
{ ...

Be aware that the @Transactional annotation can only be used to annotate public methods.

The WebSphereUowTransactionManager supports each of the Spring transaction attributes:
o PROPAGATION_REQUIRED
o PROPAGATION_SUPPORTS
o PROPAGATION_MANDATORY
o PROPAGATION_REQUIRES_NEW
o PROPAGATION_NOT_SUPPORTED
o PROPAGATION_NEVER

For earlier versions of Spring that do not provide org.springframework.transaction.jta.WebSphereUowTransactionManager, and for versions of WebSphere Application Server prior to V6.0.2.19 or V6.1.0.9 that do not provide com.ibm.wsspi.uow.UOWManager, transaction support in WebSphere Application Server is available via this Spring configuration:





This configuration supports a restricted set of transaction attributes that does not include PROPAGATION_NOT_SUPPORTED and PROPAGATION_REQUIRES_NEW. The Spring class org.springframework.transaction.jta.WebSphereTransactionManagerFactoryBean, which also claims to provide PROPAGATION_NOT_SUPPORTED and PROPAGATION_REQUIRES_NEW capabilities, uses unsupported internal WebSphere Application Server interfaces and should not be used with WebSphere Application Server.
* Using Spring JMS

Just as with accessing JDBC data sources, Spring applications intended to access JMS destinations must ensure they use WebSphere-managed JMS resource providers. The same pattern of using a Spring JndiObjectFactoryBean as a proxy for a ConnectionFactory will ensure that JMS resources are properly managed.

For JMS message sending or synchronous JMS message receipt, JMSTemplates can be used. This includes the use of Spring’s dynamic destination resolution functionality both via JNDI and true dynamic resolution.

The following example shows the configuration of a resource reference for a ConnectionFactory. This reference is mapped during application deployment to point to a configured, managed ConnectionFactory stored in the application server’s JNDI namespace. The ConnectionFactory is required to perform messaging and should be injected into the Spring JMSTemplate.


jms/myCF
javax.jms.ConnectionFactory
Container
Shareable


There is now a defined JNDI name for your ConnectionFactory within the application that can be looked up and injected into the JMSTemplate:










...








At run time, the JMSTemplate can locate destinations based on either their JNDI name (as configured in an application resource reference) or through “dynamic resolution,” based on the administrative name of the destination configured in WebSphere Application Server; for example, for the JMS myQueue queue, bound to a JNDI reference of jms/myQueue:

JNDI resolution:
jmsTemplate.send("java:comp/env/jms/myQueue", messageCreator);

Dynamic resolution:
jmsTemplate.send("myQueue", messageCreator);

As an alternative to J2EE message-driven beans (MDBs), Spring provides a message-driven POJO model for processing inbound JMS messages asynchronously. Only a DefaultMessageListenerContainer class will manage messages from the JMS queue to the configured POJO that must be a javax.jms.MessageListener implementation.

In a WebSphere Application Server environment, you must also specify a WorkManagerTaskExecutor class, which means the DefaultMessageListenerContainer class will delegate to a server-managed thread pool. The DefaultMessageListenerContainer should also be configured with the server’s transaction management via the WebSphereUowTransactionManager, as described above.





















While this message-driven POJO model can be used, it is recommended that J2EE message-driven beans (MDBs) be used directly in WebSphere Application Server configurations that require workload management and/or high availability. Be aware that no other Spring JMS MessageListenerContainer types are supported, as they can start unmanaged threads and might also use JMS APIs that should not be called by applications in a Java EE environment.
* Using JPA with Spring

The EJB 3.0 specification defines the Java Persistence API (JPA) as the means for providing portable persistent Java entities. WebSphere Application Server V7 and the WebSphere Application Server V6.1 EJB 3 feature pack both provide implementations of EJB 3 and JPA; it is also possible to use the Apache OpenJPA implementation of JPA with WebSphere Application Server V6.1 (see Resources). When Spring is used in conjunction with a JPA implementation, you should use JPA directly rather than using Spring’s JPA helper classes (in the org.springframework.orm.jpa package).

WebSphere Application Server V6.1 and later supports JPA application-managed entity managers, which might have a transaction type of either JTA or resource-local. JTA entity manager uses the application server’s underlying JTA transaction support, for which transaction demarcation can be defined using either standard J2EE techniques or Spring’s declarative transaction model, as described above.

A data access object (DAO) that uses JPA is packaged with a persistence.xml that defines persistence context for the JPA EntityManager used by the application. For example, a persistence.xml for a JTA entity manager that uses the data source with a JNDI name “java:comp/env/jdbc/springdb” can be set up like this:



org.apache.openjpa.persistence.PersistenceProviderImpl
java:comp/env/jdbc/springdb








By setting the openjpa.TransactionMode and openjpa.ConnectionFactoryMode properties to “managed,” the JPA entity manager delegates management of transactions and connections to WebSphere Application Server. The DAO may use Spring’s declarative transaction demarcation as described above.

Annotation style injection of a JPA EntityManager is also possible. This is identical to standard JPA:

@PersistenceContext
private EntityManager em;

You need this XML code to turn on EntityManager injection in the Spring XML configuration:




Spring will create an EntityManager from any EntityManagerFactory defined in this XML file. If more than one exists, then it will fail. Use one (and only one) of these ways to create an EntityManagerFactory:
o Using Spring’s basic configuration





o Using Spring’s advanced configuration







Of course, the benefits of annotations and JPA are also available by using the pure EJB 3 support in WebSphere Application Server V7 and the WebSphere Application Server V6.1 EJB 3 Feature Pack. In either case, you can create an EntityManagerFactory using the JPA API, as shown below. This approach is not recommended for a non-EJB 3 environment, because any EntityManagers created might not be properly managed. However, when you do have an EJB 3 environment, you can use this approach to separate your Spring and JPA configurations.


* Spring EntityManagerFactory and JPA When using JPA, there is a conflict in the Spring EntityManagerFactory that requires configuring the entityManagerFactoryInterface property. This issue and its resolution are documented on the Spring Web site. * IBM JDK 6 WebSphere Application Server V7 runs on IBM JDK 6, which cannot be used with versions of the Spring framework prior to V2.5.5, due to a Spring problem documented within this JIRA. Spring security considerations Spring provides a security framework that differs significantly from the standard Java EE security framework. In some cases, this framework can rely on the underlying Java EE security runtime, and in other cases, the Spring security framework completely replaces it. The Spring implementation of an authentication provider enables integration with the container, but only at the level of calling a specific subroutine, org.springframework.web.filter.DelegatingFilterProxy, which is implemented as a servlet filter and configured in web.xml for the url pattern /* so that it gets called on every request. In terms of applicability to WebSphere Application Server authentication, see this article on the WebSphere Application Server authentication process and various options for extending or customizing WebSphere Application Server authentication before you proceed with any of the three common use patterns listed below — or any other implementation using org.springframework.web.filter.DelegatingFilterProxy: * The servlet filter is employed to replace J2EE container security. In this case, WebSphere Application Server J2EE security is not used. Either security is not enabled, or, if it is employed, no J2EE authorization constraint is defined in the web.xml. Spring security has its own security context (stored in the HTTP session for a user, by default) and uses GrantedAuthority objects to determine a user’s permissions on resources. The Spring security context is used for all authorization decisions. Since there is no Java EE security context, none of the WebSphere Application Server security features (such as, authorization, SSO integration with proxies, Java EE application SSO, SPNEGO integration, identity propagation to EJBs, services, databases, and so on) apply. * The servlet filter is used in conjunction with a Spring “pre-authenticated authentication provider,” which is conceptually similar to a WebSphere Application Server Trust Association (TAI). Here, J2EE security is enabled and there is a J2EE authorization constraint in the web.xml, so normal container authentication takes place. The pre-authenticated authentication provider extracts the username from the runtime and then calls isUserInRole() on a set of predefined roles. These roles are mapped to GrantedAuthority objects, and from then on the Spring security context is used. In this case, there is a valid Java EE security context and WebSphere Application Server security features are available — with the caveat that Spring-specific security features might or might not honor WebSphere Application Server security behavior. One such example is that it is possible to change the identity on a thread using WebSphere Application Server APIs, but that behavior may or may not be consistent when Spring security is employed. * The servlet filter is used in conjunction with a Spring JAAS authentication provider. As with the first case listed, WebSphere Application Server J2EE security is likely not even enabled, or, if it is, there is no J2EE authorization constraint defined in the web.xml. However, the actual task of authenticating the credentials obtained by the filter is delegated to the container by use of what is (from the WebSphere Application Server point of view) an application JAAS login. The login module and login configuration used are specific to the container in use, and Spring callback handlers are supplied to provide the username and password of the user. When the login is complete, the principals are obtained from the subject using loginContext().getSubject().getPrincipals(), and they are passed to a piece of code called an AuthorityGranter, which decides what GrantedAuthority objects to grant based on the Principal objects; be aware that the GrantedAuthority objects are not based on J2EE roles here. From here on, the Spring security context is used. However, from a WebSphere Application Server security perspective, the ltpaLoginModule is only a small part of the security runtime and this module is not designed to be called in isolation; rather, it is designed to be called as part of a login configuration to instantiate a JAAS subject. The actual instantiation of the JAAS subject is done by a second module, com.ibm.ws.security.server.lm.wsMapDefaultInboundLoginModule. It is only after this second login module is called that a WebSphere Application Server security context is created. As a result, because the WebSphere Application Server login module in question is not intended to be used this way, using it directly in the manner described has unpredictable consequences. Moreover, users implementing this approach have encountered serious performance issues, in addition to suffering from the same limitations mentioned in the first pattern. Of these, only the second use case listed above can be considered true “integration” because J2EE security is used for authentication and the Spring security context is used for subsequent authorization — although since the Spring security context is stored by default in the HTTP session (which is a security anti-pattern because HTTP session is not secure), you should steer clear of the default. If you choose to employ this pattern, you must to go to extra lengths to protect the session — which is not normally considered to be part of the security infrastructure; for example, you’ll need to protect the session cookie and should enable WebSphere Application Server session security integration. (See WebSphere Application Server V7 advanced security hardening for more.) Rather than storing Spring security context in an HTTP session, a better option would be to extend Spring to store the context in the JAAS subject instead, which will require additional custom development. As mentioned elsewhere in this article, this guidance should not be considered to be exhaustive. The points presented here with respect to Spring security do not constitute a discussion of all possible implications of using Spring security; rather, it is simply a list of issues that users have encountered from the inappropriate use of Spring security. While it might be possible to extend Spring security to provide reasonably secure integration with WebSphere Application Server and other Java EE applications that do not use Spring, you should always leverage the security implementation provided by WebSphere Application Server for applications running in WebSphere Application Server. Not only will this ensure robust and reliable security integration, but the security that is provided will be fully supported within WebSphere Application Server. One feature of Spring security that users seem to like is the authorization framework, which goes beyond what native Java EE authorization provides. If this is your primary reason for considering Spring security, you should investigate other, less disruptive options, such as IBM Tivoli Security Policy Manager or writing your own custom authorization, perhaps using your own access control lists. Using HttpSessionContextIntegrationFilter and forceEagerSessionCreation You should always use WebSphere Application Server security mechanisms to secure your WebSphere Application Server applications. If you use the Spring Security filter HttpSessionContextIntegrationFilter, however, here is a problem scenario you should watch for. HttpSessionContextIntegrationFilter executes after the call to the WebSphere Application Server server-side application code has been made; for example, the filter runs after a call to index.jsp has been made, which returns response data. As a result, the response will already have been committed when the call to create a session is reached in the Spring filter, and so the HTTP headers have already been returned. Since a Set-Cookie header must be added to the HTTP response, and the response has already been sent, a Java EE compliant container (such as WebSphere Application Server) might throw an IllegalStateException causing the Set-Cookie to fail. It has been observed that this exception is suppressed in at least some versions of Spring Security, which might lead to a NullPointerException later on — making it very difficult to determine exactly what happened. To avoid this problem, you can set the forceEagerSessionCreation option on the HttpSessionContextIntegrationFilter entry to true in your Spring configuration: Integration and management considerations * JMX and MBeans Spring JMX MBeans are supported on WebSphere Application Server V6.1 and later only when registered with WebSphere Application Server’s container manager MBeanServer. If no server property is specified, the MBeanExporter tries to automatically detect a running MBeanServer. When running an application in WebSphere Application Server, the Spring framework will therefore locate the container’s MBeanServer. You should not use MBeanServerFactory to instantiate an MBeanServer and then inject it into the MBeanExporter. Furthermore, the use of Spring’s ConnectorServerFactoryMBean or JMXConnectorServer to expose the local MBeanServer to clients by opening inbound JMX ports is not supported with WebSphere Application Server. Spring JMX MBeans are not supported on WebSphere Application Server prior to Version 6.1. * Registering Spring MBeans in WebSphere Application Server WebSphere Application Server MBeans are identified by a javax.management.ObjectName when they are registered that looks like this: WebSphere:cell=99T73GDNode01Cell,name=JmxTestBean,node=99T73GDNode01, process=server1,type=JmxTestBeanImpl This means that when they are de-registered, they need to be looked up with the same “fully qualified” name, rather than the simple name property of MBean. The best approach is to implement org.springframework.jmx.export.naming.ObjectNamingStrategy, which is an interface that encapsulates the creation of ObjectName instances and is used by the MBeanExporter to obtain ObjectNames when registering beans. An example is available on the Spring Framework forum. You can add the ObjectNamingStrategy instance to the bean that you register. This will ensure that the MBean is properly de-registered when the application is uninstalled. ... * MBeans ObjectNames and notifications Due to the use of a fully qualified ObjectName for MBeans in WebSphere Application Server, you are advised to fully define that ObjectName to use notifications. This JIRA enables the Spring bean name to be used instead and should provide a fix, but only if you are on the appropriate version of Spring. * System z multicall/unicall limitation As Spring doesn’t allow the specification of platform-specific fields in the MBean descriptor, Spring JMX will work on multi-SR servers on WebSphere Application Server V6.1, but you are restricted in your deployment options. WebSphere Application Server will default to the unicall strategy so that only one instance of the MBean (in one, indeterminate SR) will be asked to execute a request. This may be sufficient in some scenarios but it is more likely that an application will require the ability to declare a combination of multicall and unicall methods, and possibly result in aggregation logic. * Scheduling and thread pooling Spring provides a number of TaskExecutor classes that can be used for scheduling work. The only Spring TaskExecutor that is supported by WebSphere Application Server for executing work asynchronously is the Spring WorkManagerTaskExecutor class, which properly utilizes thread pools managed by WebSphere Application Server and delegates to a configured WorkManager. Other TaskExecutor implementations might start unmanaged threads. You can setup a WorkManager within the WebSphere Application Server administrative console by navigating to Resources => Asynchronous beans => Work managers . The JNDI name for the resource can then be used in the Spring config file as a workManagerName property to define a WorkManagerTaskExecutor. This example uses WebSphere Application Server’s DefaultWorkManager JNDI name or wm/default: * Classloaders Spring and WebSphere Application Server both use several open source projects and, unfortunately, the versions of the projects they have in common won’t always match. Spring dependencies should be packaged as part of the application, and the server should be setup as described below to avoid conflicts. Otherwise, the classloaders may not load the appropriate version either for the runtime or for the application. Usually, this will cause exceptions to appear in the log regarding version mismatches of classes, ClassCastExceptions, or java.lang.VerifyErrors. One example is the use of Jakarta Commons Logging. Configuring Jakarta Commons Logging (JCL) for application use, or utilizing a different version of JCL than is provided by the application server (for example, embedded with the application code) requires specialized configuration on WebSphere Application Server. See Integrating Jakarta Commons Logging for strategies on how to configure a deployed application to use an embedded version of commonly used technologies. Keep an eye on the support Web site for updates on how to configure embedded JCL on WebSphere Application Server V6.x products. This is just one example of conflicts. Others might include application use of JDOM or specific versions of JavaMail. Replacement of WebSphere Application Server’s JAR files with these or other packages with later or different versions is not supported. Another classloader problem that may plague Spring users on WebSphere Application Server is the way Spring loads resources. Resources can include things such as message bundles, and with the classloader hierarchy and various policies for locating resources within the hierarchy, it is possible for resources using a common name to be found in an unintended location. The WebSphere Application Server classloader viewer can be used to help resolve this problem. The combination of this and other versions of common libraries may require that the application rename resources to a unique name. The example explained by James Estes on the Spring forum contains an EJB project and a Web project packaged into an EAR file. The solution described is to add the spring.jar file into both the WEB-INF/lib and the top level of the EAR, then set the classloader policy for the WEB project to PARENT LAST so that it finds the version in WEB-INF/lib first. The EJB project uses the version in the EAR. Design considerations Some of the infrastructure services provided by the Spring Framework replicate services provided by a standards-based application server runtime. Furthermore, the abstraction of the Spring framework infrastructure from the underlying J2EE application server necessarily weakens the integration with application server runtime qualities of service, such as security, workload management, and high availability. As a result, using the Spring Framework in applications deployed into the WebSphere Application Server must be carefully considered during application design to avoid negating any of the qualities of service provided by WebSphere Application Server. Where no other recommendation is made, directly using the services provided by WebSphere Application Server is preferred in order to develop applications based on open standards and ensure future flexibility in deployment. * Unmanaged threads There are some Spring scenarios that can lead to unmanaged thread creation. Unmanaged threads are unknown to WebSphere Application Server and do not have access to Java EE contextual information. In addition, they can use resources without WebSphere Application Server knowing about it, exist without an administrator’s ability to control their number and resource usage, and impede on the application server’s ability to gracefully shutdown or recover resources from failure. Applications should avoid any scenario that causes unmanaged threads to be started, such as: o registerShutdownHook Avoid using the Spring AbstractApplicationContext or one of its subclasses. There is a public method, registerShutdownHook, that creates a thread and registers it with the Java VM to run on shutdown to close the ApplicationContext. Applications can avoid this by utilizing the normal lifecycle notices they receive from the WebSphere container to explicitly call close on the ApplicationContext. o WeakReferenceMonitor Spring provides convenience classes for simplified development of EJB components, but be aware that these convenience classes spawn off an unmanaged thread, used by the WeakReferenceMonitor, for cleanup purposes. * Scheduling Spring provides (or integrates with) a number of scheduling packages, but the only Spring scheduling package that works with threads managed by WebSphere Application Server is the CommonJ WorkManager. Other packages, such as quartz and the JDK Timer, start unmanaged threads and should be avoided. Back to top Using Hibernate Hibernate is an open source persistence framework for POJOs, providing object-relational mapping of POJOs to relational database tables using XML configuration files. The Hibernate framework is a data access abstraction layer that is called by your application for data persistence. Additionally, Hibernate provides for the mapping from Java classes to database tables (and from Java data types to SQL data types), as well as data query and retrieval capabilities. Hibernate generates the requisite SQL calls and also takes care of result set handling and object conversion. Hibernate, like OpenJPA, implements the Java Persistence APIs (JPA) specification, which is a mandatory part of Java EE 5. (See Resources for developerWorks articles on using Hibernate.) Usage scenarios The following scenarios describe some of the possible scenarios for how to use Hibernate with WebSphere Application Server and WebSphere stack products. These are only example scenarios and should not be considered recommended scenarios. * Use a WebSphere Application Server data source In order for Hibernate to get database connections from WebSphere Application Server, it must use a resource reference, as mandated by the Java EE (formerly known as J2EE) specification. This ensures WebSphere Application Server can provide the correct behavior for connection pooling, transaction semantics, and isolation levels. Hibernate is configured to retrieve a data source from WebSphere Application Server by setting the hibernate.connection.datasource property (defined in the Hibernate configuration file) to refer to a resource reference (for example, java:comp/env/jdbc/myDSRef) defined in the module’s deployment descriptor. For example: java:/comp/env/jdbc/myDSRef Java EE resource references for Web applications are defined at the WAR file level, which means all servlets and Java classes within the container share the resource reference. Inside of an EJB module, resource references are defined on the individual EJB components. This means that, if many EJB components use the same Hibernate configuration, each EJB must define the same reference name on each EJB component. This can lead to complications that will be discussed a bit later. Once a data source is configured, one of the next steps to ensure that Hibernate works correctly is to properly configure transaction support. * Transaction strategy configuration Hibernate requires the configuration of two essential pieces in order to properly run with transactions. The first, hibernate.transaction.factory_class, defines transactional control and the second, hibernate.transaction.manager_lookup_class, defines the mechanism for registration of transaction synchronization so the persistence manager is notified at transaction end when it needs to synchronize changes with the database. For transactional control, both container-managed and bean-managed configurations are supported. The following properties must be set in Hibernate.cfg.xml when using Hibernate with WebSphere Application Server: o for container-managed transactions: org.hibernate.transaction.CMTTransactionFactory org.hibernate.transaction.WebSphereExtendedJTATransactionLookup o for bean-managed transactions: org.hibernate.transaction.JTATransactionFactory org.hibernate.transaction.WebSphereExtendedJTATransactionLookup java:comp/UserTransaction
The jta.UserTransaction property configures the factory class to obtain an instance of a UserTransaction object instance from the WebSphere container.

The hibernate.transaction.manager_lookup_class property is supported on the WebSphere platform by WebSphere Application Server V6.x and later, and on WebSphere Business Integration Server Foundation V5.1 and later. This property configures Hibernate to use the ExtendedJTATransaction interface, which was introduced in WebSphere Business Integration Server Foundation V5.1 and WebSphere Application Server V6.0. The WebSphere ExtendedJTATransaction interface establishes a pattern that is formalized in Java EE 5 via the JTA 1.1 specification.
* Unsupported transaction configurations

The Hibernate documentation describes transaction strategy configurations for running on WebSphere Application Server Versions 4 and 5 products; however, these configurations use internal WebSphere interfaces and are not supported on those earlier versions. The only supported transaction configuration of Hibernate is described above, which means, as stated earlier, Hibernate usage is only supported on WebSphere Business Integration Server Foundation V5.1 and on WebSphere Application Server Version 6.x and later.
* Hibernate’s usage patterns within a WebSphere Application Server environment

Hibernate’s session-per-request and long conversation patterns are both available when using Hibernate with WebSphere Application Server. Customers must choose which is appropriate for their application, though it is our opinion that session-per-request offers better scalability.
o Multiple isolation levels

Sharable connections provide a performance improvement in WebSphere Application Server by enabling multiple resource users to share existing connections. However, if sharable connections and multiple isolation levels are both necessary, then define a separate resource-ref and Hibernate session-factory for each connection configuration. It is not possible to change the isolation level of a shared connection. Therefore, it is also not possible to use the hibernate.connection.isolation property to set the isolation level on a sharable connection. See Sharing connections in WebSphere Application Server V5 for more information on policies and constraints on connection sharing. (Although this article generally pertains to all shared connection use on WebSphere Application Server V5, the connection sharing advice still follows for Hibernate running on V6.x.)
o Web applications

Hibernate long conversation sessions can be used and stored in HttpSession objects; however, a Hibernate session holds active instances and, therefore, storing it in an HttpSession may not be a scalable pattern since sessions may need to be serialized or replicated to additional cluster members. It is better to use HttpSession to store disconnected objects (as long as they are small, meaning 10KB to 50KB) and re-associate them with a new Hibernate session when an update is needed. This is because HttpSession is best used for bookmarking and not caching. A discussion on how to minimize memory use in HttpSession is contained in Improving HttpSession Performance with Smart Serialization. Instead of using HttpSession as a cache, consider using a WebSphere data caching technology like ObjectGrid or DistributedObjectCache, as described in the next section.

For best practices on high performing and scalable applications, the book Performance Analysis for Java Websites is strongly recommended.

At the time of publication, the behavior of Hibernate’s cluster aware caches in conjunction with WebSphere Application Server has not been determined; therefore, it is not yet determined whether or not their use is supported and we will not discuss them further. As a result, customers requiring a distributed cache should consider creating a class that implements org.hibernate.cache.CacheProvider using the property hibernate.cache.provider_class, which employs one of the two distributed cache implementations in WebSphere.

* Integrating a second-level cache

A Hibernate session represents a scoping for a unit of work. The Session interface manages persistence during the lifecycle of a Hibernate session. Generally, it does this by maintaining awareness or state of the mapped entity class instances it is responsible for by keeping a first-level cache of instances, valid for a single thread. The cache goes away when the unit of work (session) is completed. A second-level cache also can be configured to be shared among all sessions of the SessionFactory, including across a cluster. Be aware that caching in Hibernate raises issues that will need to be addressed. First, no effort is made to ensure the cache is consistent, either with external changes to the database or across a cluster (unless using a cluster aware cache). Second, other layers (such as the database) may already cache, minimizing the value of a Hibernate cache. These issues must be carefully considered in the application design, but they are beyond the scope of this article.

Hibernate comes with several pre-configured caches. You can find information on them in the Hibernate Cache documentation pages. For read-only data, one of the in-memory caches might be enough. However, when the application is clustered and a cluster aware cache is needed, the local read-only caches are not enough. If a distributed cache is desired, we recommend using one of the WebSphere-provided distributed cache implementations. These can be used as a second level cache with Hibernate:
o The DistributedMap/DistributedObjectCache interfaces provide distributed cache support the WebSphere v6.x product family. See Using the DistributedMap and DistributedObjectCache interfaces for the dynamic cache for more information.
o ObjectGrid, available as part of the WebSphere Extended Deployment product, provides extensible object caching support. See ObjectGrid for more information.
* Using Hibernate in WebSphere Enterprise Service Bus and WebSphere Process Server

WebSphere Process Server and WebSphere Enterprise Service Bus (ESB) rely on the Service Component Architecture (SCA) and Service Data Objects (SDO) as an assembly and programming model for SOA. (See Resources to learn more about SCA and SDO.) SCA components are not Java EE components, so they do not have resource references, but rely instead on services and adapters to connect to systems. Resource references cannot be used when building Java SCA components; therefore, Hibernate cannot be used directly by an SCA component.

In this case, Hibernate persistence should be hidden behind some kind of facade. There are two alternatives:
o A local EJB session facade is created to wrap Hibernate persistence. The session facade provides adapter logic to map Hibernate entity POJOs to Service Data Objects and back. An integration developer can then use an EJB import to invoke the session facade, and invoke it in a tightly coupled fashion with corresponding Qualities of Service (QoS).
o An EJB Web service session facade is created to wrap Hibernate persistence. An integration developer can then use a Web service import to invoke the Web service for persistence. This gets around having to build POJO to SDO converters, since at the current time SCA only uses SDO for data types. Figure 1 illustrates a business process using both patterns, though the details of the process are beyond the scope of this article.

Figure 1. Sample business process
Figure 1. Sample business process
* Hibernate JPA API on WebSphere Application Server V6.1

Hibernate’s JPA support provides for JPA standard persistence and is a good alternative to the proprietary Hibernate APIs. Hibernate’s JPA implementation requires a Java SE 5 based runtime, and therefore only runs on WebSphere Application Server V6.1 or later. At the time of publication, Hibernate’s JPA support does not run on WebSphere System z or iSeries platforms. The Hibernate documentation describes how to package and deploy applications using Hibernate’s JPA implementation.
* Non-interoperable / Non-portable function

Section 3.2.4.2 in the JPA specification describes a scenario that is likely to cause interoperability and potential portability problems. This has to do with the combination of the use of lazy loading (that is, @Basic(fetch=LAZY)) and detached objects. When merging a detached object back into a session, JPA will examine the object and update the data store with any changed values. However, data objects are simple POJOs. If part of the POJO state wasn’t loaded when it was detached, it can appear to be changed when it is merged back in. To get this to work correctly, vendors must implement serialization techniques specific to their runtime. This is not interoperable and the semantics may not be portable either.

Back to top

Product and customer technical support

An area of reasonable concern for users is support of projects using open source and the impact of that usage upon a vendor’s support for its licensed products. IBM recognizes that some customers may desire to use non-IBM frameworks in conjunction with IBM WebSphere Application Server and is providing information to customers that may promote the creation of the most reliable operating environment for IBM WebSphere Application Server. IBM considers open source code and application frameworks installed by customers, either bundled as part of the application or as shared libraries, to be part of application code. By carefully utilizing this information when using open source projects, customers may use IBM products with a higher degree of confidence that they may have continued access to IBM product and technical support. If a problem is encountered when using these frameworks with WebSphere products, IBM will make reasonable efforts to ensure the problem does not lie with the WebSphere product.

It is expected that customers may safely use frameworks such as Spring and Hibernate on IBM products by observing the suggestions of this article and understanding a few key points:

* Customers must ensure that they only use those frameworks in ways that are allowed by WebSphere Application Server. In particular, this means that frameworks should not be used when they use internal product interfaces — unfortunately many open source frameworks do this when not configured carefully. Customers should avoid scenarios clearly documented as things to avoid on WebSphere.
* For open source frameworks, customers should ensure they understand and have access to matching source code and binaries for the framework they are using with WebSphere Application Server.
* Customers are encouraged to obtain corrective service for the frameworks from the open source community or from partners working with the open source community.

For more details on IBM support and policy please refer to the IBM Support Handbook and WebSphere Application Server Support Statement.

Although following the suggested practices of this article will help you enhance your experience when using WebSphere Application Servers in an open source environment, it is not an all inclusive list of ways in which an open source component may impact WebSphere Application Server operation or the operation of other components. Users of open source code are urged to review the specifications of all components to avoid licensing, support, and technical issues.

Throughout this article, the terms “support” or “supported” indicates that the usage being described uses only IBM documented functionality. The authors have done their best to provide advice on how to configure and use these frameworks to ensure that their usage is consistent with documented product behavior, but this article is neither an endorsement nor a statement of support for Spring or Hibernate.

More Here

Courtesy:http://skysoftarchive.wordpress.com/2010/11/21/using-spring-and-hibernate-with-websphere-application-server/