by Paco Gomez
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.
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.
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.
The ideal situation is to eliminate the service enablement layer and have ALSB connect directly to i5/OS programs. This approach provides:
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:
Let's look at some of the details.
Pages: 1, 2