How isCOBOL for Axis2 handles SOAP messages isCOBOL for Axis2 can handle processing for both the sender and the receiver in a transaction. From the isCOBOL for Axis2 perspective, the structure looks like this: On each end, you have an application designed to deal with the (sent or received) messages. In the middle, you have isCOBOL for Axis2. Or rather, you CAN have isCOBOL for Axis2. The value of Web services is that the sender and receiver (each of which can be either the server or the client) don't even have to be on the same platform, much less running the same application. But assuming that isCOBOL for Axis2 is running on both sides, the process looks like this: • The sender creates the SOAP message. • Axis "handlers" perform any necessary actions on that message such as encryption of WS-Security related messages. • The Transport sender sends the message. • On the receiving end, the transport listener detects the message. • The transport listener passes the message on to any handlers on the receiving side. • Once the message has been processed in the "pre-dispatch" phase, it is handed off to the dispatchers, which pass it on to the appropriate application. In isCOBOL for Axis2, these actions are broken down into "phases", with several pre-defined phases such as the "pre-dispatch", "dispatch," and "message processing" being built into isCOBOL for Axis2. Each phase is a collection of "handlers". isCOBOL for Axis2 enables you to control what handlers go into which phases, and the order in which handlers are executed within phases. You can also add your own phases and handlers. Handlers come from "modules" that can be plugged into a running isCOBOL for Axis2 system. These modules, such as Rampart, which provides an implementation of WS-Security, and Sandesha, which provides an implementation of WS-ReliableMessaging, are the main extensibility mechanism in isCOBOL for Axis2.
