Using WebSphere ESB V6.2 as a Web services bridge between isolated IPv6 and IPv4 networks

Transitioning to the IPv6 Internet protocol is inevitable. Migrating systems and applications from IPv4 to IPv6 will employ multiple techniques and significant effort over the coming years. Extending legacy services into IPv6 domains will be required to facilitate the adoption of IPv6 and the development of new enterprise services. One option, which protects investment in legacy assets, can be to use an Enterprise Service Bus (ESB) capable of protocol translation between IPv4 and IPv6 networks. This article explains how to deploy IBM® WebSphere® ESB V6.2 as a service bridge between isolated IPv4 and IPv6 networks. This content is part of the IBM WebSphere Developer Technical Journal.

Share:

Andras Szakal (aszakal@us.ibm.com), Distinguished Engineer , IBM

Andras Szakal is an IBM Distinguished Engineer and the Chief Software IT Architect for the Federal Software Group. Mr. Szakal holds an undergraduate degree in Biology and Computer Science and a Masters in Computer Science from James Madison University.



Bhargav Perepa (bvperepa@us.ibm.com), Integration Technology Specialist, IBM

Bhargav Perepa is a WebSphere IT Specialist at IBM Federal Software Group in Washington D.C. area. He was a WebSphere developer in IBM Austin WebSphere Development Lab and had previous Smalltalk, C++ development experience in IBM Chicago. Bhargav holds a Masters degree in Computer Sciences from IIT, Chicago and an MBA degree from UT-Austin, Texas. You can reach Bhargav at bvperepa@us.ibm.com.


developerWorks Contributing author
        level

Jennifer Koehl (jennifer_koehl@us.ibm.com), Architect-in-Residence , IBM

Jennifer Koehl is the IBM Federal Software Architect-in-Residence at the McLean Technical Exploration Center in McLean, VA.



04 March 2009

Introduction

If you’ve been happily stranded on a deserted island somewhere in the South Pacific for the last few years -- without WiFi -- then you might not have heard that the world is running out of IPv4 address space. It’s simply a matter of time before you will be required to migrate to the latest version of the Internet Protocol, Version 6 (IPv6). Aside from increased address space, other valid reasons to migrate from IPv4 to IPv6 include a more simplified network topology, content-based network routing, and security features, such as IPSec. Transitioning to IPv6 is not really a matter of if (it will happen), or even when (soon), it’s a matter of how.

The old saying ”the current run time rules” implies that your current IT infrastructure dictates future technology choices. While IPv4 (the current address scheme) provides more than 4 billion unique addresses, there are many more network-based devices using the Internet, each needing its own unique address. In fact, we have already technically exhausted the number of unique addresses that can be provided directly by IPv4. In the absence of enough address space, network engineers designed sub-optimal “workarounds,” like Network Address Translations (NAT) and extensions to the IPv4 specification, which enabled a temporary increase in the number of addressable network devices. NAT and other IPv4 extensions have merely delayed the inevitable exhaustion of possible IPv4-based network addresses. Today, we can no longer sustain the growth of network-based devices using IPv4 and are now essentially forced to move to IPv6.

Unfortunately, NAT and other IPv4 extensions have not only increased the possible number of IPv4 addresses, but also significantly increased the complexity of network topologies, which in turn impacts network performance, manageability, and security. IPv6 alleviates the need to deploy similar sub-optimal network architectures; however, it does not prevent similar topologies. Therefore, when deploying a new IPv6 infrastructure network architecture, you must avoid deploying a v6-based network architecture that mirrors the existing v4 architecture. Overlaying an IPv6 network topology over an existing IPv4 infrastructure would significantly diminish the value of the transition and potentially cause performance and security issues. (See U.S. Federal IPv6 Transition Guidance for details.)

One option that facilitates transition from IPv4 to IPv6 is the use of dual stack enabled IT components. This requires that both network and application components have the ability to manage both IP stacks and route messages regardless of network protocol.

By deploying a dual IPv4/IPv6 stack solution, IT components can interoperate by effectively translating one address scheme to another. This strategy enables existing IPv4 components to communicate directly with IPv6-enabled applications and network components without the need to expend resources to migrate existing components to IPv6. While dual stack is a valuable method of facilitating interoperability, it does not enable the use of advanced IPv6 capabilities (for example, content-based routing) from IPv4-based devices.

Figure 1. Bridging IPv4 to IPv6
Figure 1. Bridging IPv4 to IPv6

Most legacy IT systems, applications, and vendor product deployments will need remediation in order to migrate to an IPv6 network. Some legacy IT systems and components may never be candidates for migration to IPv6, especially if the vendor does not plan to remediate back-leveled components. Migration of existing IT systems will stretch over many years. For these reasons, you need a method for interoperating between existing IPv4-based systems and the growing number of IPv6 systems that avoids the need to mirror the existing IPv4 topology when a new IPv6 network is deployed. A dual stack strategy should only be employed as a gateway between the existing IPv4 network domain and the ever growing IPv6 domain, as shown in Figure 1. Otherwise, you will fall into the dual stack trap that forces the enterprise to overlay the IPv6 domain on the existing IPv4 domain, effectively mirroring the same inefficiencies IPv6 was designed to avoid in the first place. This includes NAT segmentation, which is a by-product of the limited IPv4 address space and routing protocol. Third party gateways are available to provide a network-based solution for v4 to v6 interoperability and transition. The challenge with these network-based gateway solutions is that they can be expensive and can stifle transition to IPv6 by creating tight bindings between IPv4-only applications and new IPv6 applications.

An Enterprise Service Bus (ESB) bridge creates loose coupling between systems and applications that facilitate migration of services to the IPv6 domain with minimal impact to existing services. An enterprise with an SOA strategy will need an ESB for mediation regardless. Alternatively, organizations can leverage their investment in their existing ESB, like IBM® WebSphere® ESB, which provides support for IPv4 to IPv6 protocol translation. This provides an alternative that bypasses the need for additional network hardware and investment.

An ESB, with mediations, performs these services between a requester and service:

  • Routes messages between services.
  • Converts transport protocols between requester and service.
  • Transforms message formats between requester and service.
  • Handles business events from disparate sources.

WebSphere ESB provides a message and event-driven messaging infrastructure based on service-oriented standards. An ESB provides mediation services that enable the transformation of messages to different formats and protocols. WebSphere ESB provides the ability to convert transport protocols between the requester and the invoking service (Figure 2), and enables the definition of the IP version (v4 or v6) when defining the protocol requirements for endpoints. The translation from IPv4 to IPv6 occurs within the ESB and requires no additional programming.

Figure 2. ESB protocol mediation
Figure 2. ESB protocol mediation

The ESB routes messages between applications, which are requesters or service providers. The ESB converts transport protocols and transforms message formats between requesters and providers. You can leverage this ESB capability by deploying it to create an IP bridge between the IPv4 cloud and the IPv6 cloud. This technique provides loose coupling between application services in an IPv4 domain and those in an IPv6 domain. IPv6-based systems and applications can then leverage IPv4 legacy applications using an SOA interface by using the mediation and protocol transformation services of the ESB.

In Figure 3, each application uses a different IP protocol and different message formats. There is no direct IP route between application A and application B. A node corresponds to a logical or physical computer system with a distinct IP host address. Node names usually correspond to the host name for a specific computer.

Figure 3. ESB bridge architecture
Figure 3. ESB bridge architecture

The ESB protocol bridge architecture provides a method to extend and advertise IPv4-based services into the IPv6 domain. The next sections of this paper describe how to setup and test the protocol bridge architecture using WebSphere ESB.


Configuring the environment

To create an environment that supports the notion of bridging services across isolated networks, you will need to have (Figure 4):

  • An ESB server that is only available via an IPv4 address.
  • An ESB server that is only available via an IPv6 address.
  • A DNS server and another ESB server that are on a dual stack network that enables them to communicate with each other.

This can easily be configured via the DNS server entries. It is possible to configure the deployment topology by having only IPv4 address entries for servers in the IPv4 network, IPv6 address entries for servers in the IPv6 network, and two sets of entries -- one with an IPv4 address and one with an IPv6 address -- for each server in the dual stack network (Figure 5 shows a forward lookup example, Figure 6 shows a reverse lookup example).

Figure 4. Network configuration
Figure 4. Network configuration
Figure 5. DNS entries: Forward lookup zones
Figure 5. DNS entries: Forward lookup zones
Figure 6. DNS entries : Reverse lookup zones
Figure 6. DNS entries : Reverse lookup zones

Configuring the sample application

When you have the network configured, you can build and configure a simple application that will utilize the ESB on the dual stack network to pass services from each of the isolated networks to the other. Figure 7 summarizes the application topology with various J2EE™ and ESB mediation applications running on indicated hosts.

Figure 7. Summary of network topology
Figure 7. Summary of network topology

The sample application components described here are available in the download file included with this article. Within this file, you will find the EAR files deployed on each of the servers described above. Additionally, a text file defining the explicit URLs for the applications are included for each server. These application components, when used together, will provide the basic mechanism for bridging services on isolated networks utilizing WebSphere ESB:

  • AboutSelfServiceEAR.ear

    This J2EE application implements the core “heartbeat” and “who am I” logic:

    • aboutMe() method provides the capability for the “who am I” request. It takes no parameters and returns a string literal of “Server” or “Client” when invoked.
    • aboutMyCommunity() method provides the capability for the “heartbeat” request. It takes no parameters and returns a string literal containing the server name, such as “IPv6-IPv6” or “IPv6-ESB” or “IPv6-IPv4”, depending on where this implementation is hosted and running.

    Participants in an exchange can be clients or servers.

  • AboutSelfServiceClientEAR.ear

    This J2EE application implements universal client logic in a JavaServer™ Page (JSP). This application takes a parameter as an input and invokes “who am I” and “heartbeat” methods on an appropriately chosen local or remote implementation.

  • IPMediationModuleApp.ear

    This mediation application runs on each server. It provides an Service Component Architecture (SCA) wrapper to the AboutSelfServiceEAR.ear implementation running on the same server. This application uses the delegation pattern.

  • IPV6_624_ProxyApp.ear

    This mediation application runs on the IPv6-IPv6 server. It provides a proxy SCA wrapper façade to the remote AboutSelfServiceEAR.ear implementation running on the IPv6-IPv4 server. This application uses the delegation pattern to delegate the call to the ESB_624_MedModApp mediation application running on the IPv6-ESB server.

  • IPV6_426_ProxyApp.ear

    This mediation application runs on the IPv6-IPv4 server. It provides a proxy SCA wrapper façade to the remote AboutSelfServiceEAR.ear implementation running on the IPv6-IPv6 server. This application uses the delegation pattern to delegate the call to the ESB_426_MedModApp mediation application running on the IPv6-ESB server.

  • ESB_624_MedModApp.ear
    ESB_426_MedModApp.ear

    These mediation applications run on the IPv6-ESB server. They provide mediation between IPv6 and IPv4 network islands, and use the delegation pattern to delegate the calls to the AboutSelfServiceEAR.ear implementation running on IPv6-IPv6 or IPv6-IPv4 servers.

Table 1 summarizes the distributed deployment of the various applications on the network topology shown in Figure 7.

Table 1. Summary of application deployment
Program namePurposeHosted serverRemarks
AboutSelfServiceClientEAR.earUniversal clientAllUniversal client runs on each server.
AboutSelfServiceEAR.ear“heatbeat” and “who am I” server implementationAllEach server implements its own version of logic.
IPMediationModuleApp.earSCA wrapperAllSCA wrapper to delegate requests to server-specific implementation logic.
IPV6_624_ProxyApp.earIPv4 proxy to all IPv6 clientsIPv6-IPv6Runs on the edge of IPv6 boundary as proxy to the other IPv4 island.
IPV4_426_ProxyApp.earIPv6 proxy to all IPv4 clientsIPv6-IPv4Runs on the edge of IPv4 boundary as proxy to the other IPv6 island.
ESB_426_MedModApp.earIPv4-to-IPv6 mediation bridgeIPv6-ESBRuns only on ESB server. This is where the mediation logic bridges IPv4 and IPv6 islands.
ESB_624_MedModApp.earUniversal clientIPv6-ESBRuns only on ESB server. This is where the mediation logic bridges IPv6 and IPv4 islands.

Running the application using the ESB bridge

The sample application described above, when configured on this network architecture, can be utilized to exhibit the ability of WebSphere ESB on a dual stack network to bridge services between single stack networks. To do this, you will need to run a combination of scenarios. Each of these scenarios can be realized by entering a definitive input value in the Endpoint Tier field presented in the browser when loading the application’s URL. Table 2 describes the service invoked and provides related remarks based on the input value entered into the Endpoint Tier field.

Table 2. Summary of input options
Input valueInvoked implementation serverRemarks
1IPv6-IPv6 -- AboutSelfServiceThis is a valid option only on IPv6-IPv6 and IPv6-ESB servers. This option invokes implementation directly. This is an invalid option on IPv6-IPv4 server because this server cannot directly communicate with IPv6-IPv6.
2IPv6-ESB -- AboutSelfServiceThis is a valid option on all three servers, because ESB server can communicate with both IPv6 and IPv4 topologies.
3IPv6-IPv4 --AboutSelfServiceThis is a valid option only on IPv6-IPv4 and IPv6-ESB servers. This option invokes implementation directly. This is an invalid option on IPv6-IPv6 server because this server cannot directly communicate with IPv6-IPv4.
0IPv6-hostname -- AboutSelfServiceThis is a valid option on all three servers. This option invokes the implementation running on the same server as the client and uses the SCA-wrapped export URL endpoint. This is similar to “loopback” in concept.
426IPv6-IPv6 -- AboutSelfServiceThis is a valid option only on the IPv6-IPv4 server. This option invokes the IPv6-IPv6 implementation through an ESB mediation. This option makes use of mediation application ESB_426_MedModApp running on IPv6-ESB.
624IPv6-IPv6 -- AboutSelfServiceThis is a valid option only on the IPv6-IPv6 server. This option invokes hte IPv6-IPv4 implementation through an ESB mediation. This option makes use of mediation application ESB_624_MedModApp running on IPv6-ESB.

To run the universal client on any server, launch a browser and point the URL to http://hostname:port/AboutSelfServiceClient/AboutSelfServiceClient.jsp, where hostname can take the values of (in this example) “IPv6-IPv6” or “IPv6-ESB” or “IPv6-IPv4” and port number be 9080 (depending on installation order). When you run this client, you have the option of entering one of several values into a field, called Endpoint Tier. What the application does then depends on the value entered. Table 3 summarizes the endpoint URLs and some remarks for each input option on each host.

Table 3. Summary of testing configurations
ServerInput valueEndpoint URLRemarks
IPv6-IPv6NAhttp://IPv6-IPv6:9080/IPMediationModuleWeb/sca/AboutSelfInterfaceExportSample application running validation.
NAhttp://IPv6-IPv6:9080/AboutSelfService/services/AboutSelfInterfaceSample application running validation.
NAhttp://IPv6-IPv6:9080/AboutSelfServiceClient/AboutSelfServiceClient.jspSample application running validation.
0NAPermitted, should succeed.
1NAPermitted, should succeed.
2NAPermitted, should succeed.
3NAPermitted, should fail.
624NAPermitted, should succeed.
IPv6-IPv4NAhttp://IPv6-IPv4:9080/IPMediationModuleWeb/sca/AboutSelfInterfaceExportSample application running validation.
NAhttp://IPv6-IPv4:9080/AboutSelfService/services/AboutSelfInterfaceSample application running validation.
NAhttp://IPv6-IPv4:9080/AboutSelfServiceClient/AboutSelfServiceClient.jspSample application running validation.
0NAPermitted, should succeed.
1NAPermitted, should fail.
2NAPermitted, should succeed.
3NAPermitted, should succeed.
IPv6-ESBNAhttp://IPv6-ESB:9080/IPMediationModuleWeb/sca/AboutSelfInterfaceExportSample application running validation.
NAhttp://IPv6-ESB:9080/AboutSelfService/services/AboutSelfInterfaceSample application running validation.
NAhttp://IPv6-ESB:9080/AboutSelfServiceClient/AboutSelfServiceClient.jspSample application running validation.
0NAPermitted, should succeed.
1NAPermitted, should succeed.
2NAPermitted, should succeed.
3NAPermitted, should succeed.
426NAPermitted, should succeed.

Sample of input values and responses

Figures 8 and 9 illustrate results received on the IPv6-IPv6 host when the input value of “0” is entered into the Endpoint Tier field of the sample application.

Figure 8. Input value 0
Figure 8. Input value 0
Figure 9. Input value 0 -- Response
Figure 9. Input value 0 -- Response

This testing sequence for all Endpoint Tier field input values can be performed on each of the hosts servicing this application with success.


Summary

After configuring the network infrastructure and implementing the sample application provided with this article, you should be able to see how it is possible and advantageous to utilize IBM WebSphere ESB V6.2 within an SOA infrastructure to bridge legacy and non-legacy applications that reside on separate network protocol stacks. Deploying this model enables you to more easily migrate systems and applications from IPv4 to IPv6 networks.


Acknowledgements

The authors wish to gratefully acknowledge the help they received from Jeremy Scheer, McLean Technical Exploration Center System Administrator, for administering the test environment.

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Business process management on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Business process management, WebSphere
ArticleID=373454
ArticleTitle=Using WebSphere ESB V6.2 as a Web services bridge between isolated IPv6 and IPv4 networks
publish-date=03042009