Arch2Arch > Articles

---

Connecting BEA AquaLogic Service Bus with i5/OS and OS/400 Applications

by Paco Gómez
04/25/2007

BEA AquaLogic Service Bus (ALSB) provides the routing and transformation of messages in an enterprise system. Through ALSB, companies can integrate their i5/OS (OS/400) assets into a Service Oriented Architecture in a declarative, configuration-based approach. The ifiveos transport makes possible the direct integration between ALSB and i5/OS programs without any intermediary application server or additional coding.

This article describes how to connect ALSB directly to i5/OS and make RPG and COBOL programs reusable as services to the enterprise.

Background

The integration of i5/OS (OS/400) assets with other systems and the Web has been traditionally possible thanks to a number of adapters offered by several vendors. These adapters are used to develop service wrappers around the i5/OS programs. The service wrappers, Web services or EJBs, are, in turn, exposed to clients through the Enterprise Service Bus. The architecture is shown in Figure 1.

Figure 1. Wrappers exposing assets as Web services

A typical implementation of this architecture is made using IBM Toolbox for Java as a library to make remote calls to i5/OS programs. The developer creates Java wrappers (EJBs or Web services) that are deployed on BEA WebLogic Server or another application server. The application server may run on separate hardware, the ALSB hardware, or even i5/OS (IBM WebSphere).

In Figure 1, programs are represented with a green box and configuration-based components with a blue box.

What's Wrong with this Picture?

This isn't ideal though. Let's look at the application server box, what we could call the "service enablement" layer. These program wrappers are themselves programs that need to be developed. They can be coded by hand or generated by wizards, but in the end, they are programs that need to be maintained. Any change in the wrapped program requires a code change in the enablement layer.

The wrapper programs are also deployed on a runtime environment, adding operational costs to the total cost of this approach.

In terms of performance, an additional layer is present between ALSB and the i5/OS programs, which increases response times and can limit scalability.

A Better Approach

The ideal situation is to eliminate the service enablement layer and have ALSB connect directly to i5/OS programs. This approach provides:

• better adaptability, since the connection between ALSB and i5/OS is configured in ALSB, not coded in wrapper programs
• lower operational costs, by eliminating one complete layer
• better performance and scalability, by reducing the number of hops between clients and services

Figure 2 diagrams this improved architecture.

Figure 2. Eliminating the service enablement layer

There is an extension to ALSB that supports exactly this architecture: direct connection to i5/OS programs. This extension is the ifiveos transport. Calling i5/OS programs from ALSB is straightforward:

• Configure a business service, specifying the hostname or IP address of the i5/OS server and the login information. This is done at design time.
• Call the business service, passing an XPCML document with the name of the i5/OS program to invoke the input parameters. The response from the program will be returned as another XPCML document with the return values. This is done at run time.

Let's look at some of the details.

Pages: 1, 2

Next Page »