IBM WebSphere Application Server V7 is IBM's implementation of the Java™ Platform, Enterprise Edition (Java EE) 5 platform conforming to the J2EE™ 1.5 specification. It provides a run time environment for enterprise class applications, including J2EE applications, portlet applications, and Session Initiation Protocol (SIP) applications. WebSphere Application Server is capable of hosting enterprise applications in advanced topologies, and features workload management, scalability, high availability, and central administration.
IPv6 is the ânextâ version of the Internet Protocol, the data packaging and routing standard on which the Internet is based. IPv6 (Internet Protocol version 6) offers several improvements over the current version, IPv4. Most importantly, with 128-bit Internet addresses instead of the 32-bit addresses of IPv4, IPv6 increases the number of available addresses from about 4 billion to about 340 trillion trillion trillion addresses. Given the continued rapid growth of the Internet, ensuring there are enough addresses is crucial. The proliferation of wired and wireless devices means that multiple addresses will be required for every person who uses the Internet. IPv6 is also a strategic direction and key requirement of the federal government, along with many state and local governments and commercial organizations worldwide who are now transitioning to the new protocol.
WebSphere Application Server is a middleware hosting environment that lives on top of the native operating system platform. WebSphere Application Server does not implement TCP/IP communication protocol at the transport layer by itself; instead, WebSphere Application Server uses the native TCP/IP communication protocol provided by the host operating system platform at the transport layer. WebSphere Application Server has been certified to work within an IPv6 environment.
This article demonstrates how you can configure, deploy, and validate WebSphere Application Server topologies in pure IPv6, and in IPv6/IPv4 mixed mode infrastructure topologies. Specifically, this article covers these use cases:
WebSphere Application Server deployment topology involving pure IPv6 infrastructure and a homogeneous hosting platform environment of Microsoft® Windows®.
WebSphere Application Server deployment topology involving pure IPv6 infrastructure and a homogeneous hosting platform environment of RedHat Enterprise Linux® release 4.
WebSphere Application Server deployment topology involving pure IPv6 infrastructure and a heterogeneous hosting environment of Windows and RedHat Enterprise Linux release 4.
WebSphere Application Server deployment topology involving a mixed mode IPv6/IPv4 infrastructure and a heterogeneous hosting environment of Windows and RedHat Enterprise Linux release 4.
In order to validate WebSphere Application Server topologies, you can set up an isolated network similar to the example architecture depicted in Figure 1. (See Resources for IP related topics specific to WebSphere Application Server.)
Figure 1. Example architecture of infrastructure topology
The use cases outlined in this article were selected as a basis for validating the communication within and between two different operating systems (hosts outlined in Tables 1 and 2). This infrastructure will provide you with two hosts on two popular platforms (Windows Server 2003 and Red Hat Enterprise Linux 4.6), and the flexibility you need to test both homogenous and heterogeneous environments.
Table 1. Hosts in infrastructure topology: Windows Server 2003
|Hostname||V4 IP address||V6 IP address|
Table 2. Hosts in infrastructure topology: Red Hat Enterprise Linux 4.6
|Hostname||V4 IP address||V6 IP address|
The approach consists of testing WebSphere Application Server running on IPv6 and in a mixed mode infrastructure using the PlantsByWebSphere sample Jave EE reference application, provided with WebSphere Application Server out-of-the-box. Further testing can be performed with a sample application from another developerWorks article that demonstrates how to create a simple point-to-point JMS application using message-driven beans. This sample application makes use of the System Integration Bus (SIBus) and JMS capabilities provided by WebSphere Application Server.
For client-side testing, a Web browser client is used to call the PlantsByWebSphere application. For the JMS application, an unmanaged client is launched from the command line using the WebSphere Application Server launchClient tool. Both of these applications provide you with client/server communication atop the infrastructureâs IP stack. Because WebSphere Application Server v7 is IPv6 certified, the communication will be seamless regardless of the underlying stack version.
Configuring the operating system
You first need to determine how you would like the hosts to communicate. You can either use DNS to manipulate the IP addresses, or you can do so manually using hosts files (see Resources for Microsoftâs TechNet document summarizing Host Name Resolution).
In the cases described in this article, hosts files are used to manipulate IP addresses and thus the relevant version of their protocol. Entering an address in IPv6 format in the hosts file forces all resolution of that host to be of version 6; likewise for IPv4. When utilizing the hosts file to manipulate the means of communication, you must manually create the IP routes between hosts for IPv6 communication. To do this, you must use the following command syntax (see Resources for Microsoftâs TechNet document summarizing netsh command):
netsh interface IPv6 add address [interface=]InterfaceNameOrIndex [address=]IPv6Address [[type=]unicast|anycast] [[validlifetime=]Minutes|infinite] [[preferredlifetime=]Minutes|infinite] [[store=]active|persistent]
For example, we used these commands on the MSW2K31.mcl.us.ibm.com host to manually add the IPv6 addresses of network members, and then repeated the procedure on host MSW2K32.mcl.us.ibm.com as well.
netsh interface ipv6 add address address=fe80::202:55ff:feac:dbf/64 "Local Area Connection" netsh interface ipv6 add address address=fe80::202:55ff:feac:4121/64 "Local Area Connection" netsh interface ipv6 add address address=fe80::202:b3ff:fed2:1e31/64 "Local Area Connection" netsh interface ipv6 add address address= fe80::202:b3ff:fed3:27cc/64 "Local Area Connection"
Routes do not need to be manually configured for Linux.
To validate the communication, you can utilize the use cases summarized in Table 3 for homogeneous scenarios.
Table 3. Details of use cases tested: Homogeneous scenarios
|Use case||Client hostname||Client IP stack||Server hostname||Server IP stack||Client address||Server address||Remarks|
|1||MSW2K32||IPv6||MSW2K31||IPv6||fe80::202:55ff:feac:4121||fe80::202:55ff:feac:dbf||Figures 2 and 3|
For use case 1, you will validate v6 to v6 communication. To do this, set up the hosts file contents as shown in Figures 2 and 3. The hosts file is located in the c:\WINDOWS\system32\drivers\etc\ directory for Windows, and at /etc/hosts for Linux.
Figure 2. Client MSW2K32 hosts file contents
Figure 3. Server MSW2K31 hosts file contents
The hosts file contents is shown in Table 3 for use cases 2 through 8. For both client and server hosts, you will need to un-comment the required IPv4 or IPv6 format address lines and comment the remaining IP address lines that are not needed. You will not need to reboot between hosts file alterations, but you must save the file and close it. To validate the communication after changing the hosts file, you can ping the host using the hostname:
On Windows, use the
pingcommand from a command prompt:
If the IP version utilized in the hosts file is v4, then the replies will be in xx.xx.xx.xxx format. If the IP version is v6, then the replies will be in xxxx::xxx:xxxx:xxxx:xxxx format.
To ping via IPv6 on Linux, run this command:
> ping6 âhostname
where "hostname" is the hostname specified in your hosts file.
To validate communication for heterogeneous scenarios, you can utilize the use cases summarizied in Table 4.
Table 4. Details of use cases: Heterogeneous scenarios
|Use case||Client hostname||Client IP stack||Server hostname||Server IP stack||Client address||Server address||Remarks|
|9||rhel2||IPv4||MSW2K31||IPv6||10.69.16.173||fe80::202:55ff:feac:dbf||Figures 4 and 5|
For use case 9, set up the hosts file contents as shown in Figures 4 and 5. For use case 10, set up the hosts file contents as shown in Table 4, un-commenting the required IPv4 or IPv6 format address lines and commenting the remaining IP address lines that are not needed, for both client and server hosts.
Figure 4. Client rhel2 hosts file contents
Figure 5. Server MSW2K31 hosts file contents
Configuring WebSphere Application Server for IPv6
There are important items to consider when implementing WebSphere Application Server on an infrastructure that utilizes or will be utilizing IPv6. Some of these considerations are relevant to operating system configuration, while others are directly related to how versions of WebSphere Application Server are implemented:
When using the IBM HTTP Server on Windows, the httpd.conf file should include a Listen directive for the IPv6 address. To use the default IPv6 address, specify
Listen [::]:80. The corresponding Listen directive for an IPv4 environment would be
For applications to function in a dual stack environment, you must implement dual mode cells. Mixed IPv4 and IPv6 communications are supported in a dual mode cell. By default, a cell is set to dual mode when it is created, but only nodes running WebSphere Application Server V6 and later are valid in a dual mode cell.
When creating WebSphere Application Server profiles, you are prompted for the hostname or IP address of the machine where the profile is being created. The host name or IP address that you specify is what other nodes will use to communicate with the node being created. If you specify a host name, you need not worry about whether your system is configured for IPv4 or IPv6. As long as the DNS service is configured properly, the nodes should be able to communicate without any problems.
In many cases, you should include square brackets around an explicit IPv6 IP address. Refer to the WebSphere Application Server V7 Information Center for specific instances where brackets should not be utilized as part of an IPv6 address specification.
No configuration changes to the WebSphere environment outlined in this article are necessary to get the sample applications described below running. When configuring or installing WebSphere Application Server, and when prompted for a hostname or address, just enter the hostname.
Running the sample applications
If you are installing WebSphere Application Server as part of this exercise, an Optional Features Installation panel is displayed. Select the Install the Sample Applications option to deploy the PlantsByWebSphere sample application, which is used here to test your IPv6 environment. If you have WebSphere Application Server installed already and would like to install the PlantsByWebSphere sample application, follow the instructions in the WebSphere Application Server Information Center.
At this point, you have the operating system and WebSphere Application Server configured, so you are ready now to deploy and test the two sample applications. PlantsByWebSphere will demonstrate the use of WebSphere Application Serverâs SIBus. The other sample application from a developerWorks article will use JMS. Successful message transfer can be proven over IPv6 and IPv4/IPv6 mixed mode by following the steps below for each. Also, now that you understand the methods for manipulating the communication versions that can be used, you can test your heterogeneous and homogeneous IPv6 environments as well.
Configure the hosts file as explained above according to the use case you wish to test.
Running the PlantsByWebSphere application
Open a browser on host MSW2K32.mcl.us.ibm.com and navigate to http:// MSW2K31.mcl.us.ibm.com:9080/PlantsByWebSphere as shown in Figure 6.
Figure 6. PlantsByWebSphere browser client on Windows
Figure 7 confirms the successful execution of PlantsByWebSphere application from the clientâs perspective.
Figure 7. PlantsByWebSphere success panel
If the communication was successful, the output in the serverâs SystemOut.log should be similar to that shown in Listing 3. See the specific detailed trace outputs from each of the hosting servers named:
The trace files indicate the successful running of use cases as shown by the informational and SystemOut trace output lines, reproduced below:
Listing 3. Explicit SystemOut.log output for PlantsByWebSphere
[10/01/08 12:22:17:593 EDT] 0000001e servlet I com.ibm.ws.webcontainer.servlet.ServletWrapper init SRVE0242I: [PlantsByWebSphere] [/PlantsByWebSphere] [/product.jsp]: Initialization successful. [10/01/08 12:22:17:656 EDT] 0000001e servlet I com.ibm.ws.webcontainer.servlet.ServletWrapper init SRVE0242I: [PlantsByWebSphere] [/PlantsByWebSphere] [ImageServlet]: Initialization successful. [10/01/08 12:22:21:281 EDT] 0000001e servlet I com.ibm.ws.webcontainer.servlet.ServletWrapper init SRVE0242I: [PlantsByWebSphere] [/PlantsByWebSphere] [/cart.jsp]: Initialization successful. [10/01/08 12:22:23:046 EDT] 00000022 servlet I com.ibm.ws.webcontainer.servlet.ServletWrapper init SRVE0242I: [PlantsByWebSphere] [/PlantsByWebSphere] [/login.jsp]: Initialization successful. [10/01/08 12:22:39:937 EDT] 00000022 servlet I com.ibm.ws.webcontainer.servlet.ServletWrapper init SRVE0242I: [PlantsByWebSphere] [/PlantsByWebSphere] [/register.jsp]: Initialization successful. [10/01/08 12:23:05:578 EDT] 0000001e servlet I com.ibm.ws.webcontainer.servlet.ServletWrapper init SRVE0242I: [PlantsByWebSphere] [/PlantsByWebSphere] [AccountServlet]: Initialization successful. [10/01/08 12:23:06:062 EDT] 0000001e servlet I com.ibm.ws.webcontainer.servlet.ServletWrapper init SRVE0242I: [PlantsByWebSphere] [/PlantsByWebSphere] [/orderinfo.jsp]: Initialization successful. [10/01/08 12:23:33:015 EDT] 0000001e servlet I com.ibm.ws.webcontainer.servlet.ServletWrapper init SRVE0242I: [PlantsByWebSphere] [/PlantsByWebSphere] [/checkout_final.jsp]: Initialization successful. [10/01/08 12:23:38:796 EDT] 0000001e servlet I com.ibm.ws.webcontainer.servlet.ServletWrapper init SRVE0242I: [PlantsByWebSphere] [/PlantsByWebSphere] [/orderdone.jsp]: Initialization successful. [10/01/08 12:23:44:156 EDT] 0000001e servlet I com.ibm.ws.webcontainer.servlet.ServletWrapper init SRVE0242I: [PlantsByWebSphere] [/PlantsByWebSphere] [/shopping.jsp]: Initialization successful.
Point your browser on your client system to the Linux host running the application. For this example, an IPv6 address is used as part of our URL instead of a host name. So the URL entered was http://[fe80::202:b3ff:fed3:27c]:9080/PlantsByWebSphere, as shown in Figures 8 and 9. The IPv6 address in the URL should be enclosed by square brackets. (Older versions of some Internet browsers do not support URLs that contain IPv6 addresses, so be sure to verify that your browser version supports IPv6 before testing.)
Figure 8. PlantsByWebSphere browser client on Linux
Figure 9. PlantsByWebSphere success panel
Running the JMS client application in an IPv6 environment
To further validate WebSphere Application Serverâs messaging capabilities in your IPv6 environment, you can run a simple JMS messaging application. The sample application described in a developerWorks article on Building an Enterprise Service Bus with WebSphere Application Server V6 by Rachel Reinitz and Andre Tost is ideal for this test. The application will consist of a sender part, running within a J2EE client application, and a receiver, represented by a message-driven bean. You can successfully validate JMS communication with all the use cases through the utilization of this application. (This sample application was originally created for WebSphere Application Server V6. In our lab, the application ran as it was designed on both WebSphere Application Server V6 and V7.)
Configure the hosts file as explained above according to the use case you wish to test. For all the above use cases the successful output appears along the lines of code shown in Figures 10 and 11 and in Listing 4.
When specifying non default provider endpoints for a JMS artifact, such as an activation spec, if you specify the host address instead of the host name for the endpoint, place square brackets around the IPv6 address:
Ex [fe80::202:55ff:feac:dbf] :7276
As described in the developerWorks articles that provide this application, use the WebSphere Application Server launchClient tool to call the JMS application.
Figure 10. launchClient.bat
Figure 11. Console output
Listing 4 shows the SystemOut.log output for the sample JMS application.
[10/01/08 13:28:12:562 EDT] 0000002c SystemOut O Received message : Package Received - 24595023
Congratulations on successfully configuring and validating WebSphere Application Server v7.0 (SIBus and JMS) for pure IPv6, and for IPv6/IPv4 mixed mode cross-cell deployment topologies consisting of homogeneous and heterogeneous operating system platform environments. Through this exercise, you have seen how WebSphere Application Server, as a true middleware platform, seemlessly leverages the underlying transport infrastructures.
The authors wish to gratefully acknowledge the help received from Jeremy Scheer, McLean Technical Exploration Center System Administrator, for administering the test environment, and Geetika Tandon, WebSphere IT Specialist, for carefully reviewing this article.
|File samples||ipv6attachments.zip||46 KB|
- Building an Enterprise Service Bus with WebSphere Application Server V6, Part 3: A simple JMS messaging example
- WebSphere Application Server v7.0 Information Center
- IPv4 and IPv6 configuration for Windows operating systems
- Supported network specifications
- IP version considerations for cells
- Accessing Samples
- Microsoft TechNet â Netsh Overview
- Microsoft TechNet â Host Name Resolution
- IBM developerWorks WebSphere Application Server zone