Heshan Theekshana Suriyaarachchi
Axis2 can process SOAP messages. It consumes an incoming SOAP message and retrieves the information. This information is given to the Web service’s business logic. Afterwards, a SOAP message is generated from the result obtained from the business logic and passed back to the client. However, a problem will arise if the business logic is in Python.
The solution to the requirement of exposing a Python Web service in Axis2 lies within the pluggable deployer concept of Axis2. A deployer enables the dynamic nature of Axis2 to deploy services. In order to expose services written in Python, a custom deployer is written together with a Python message receiver. Python data types are dynamic as opposed to the static data types in XML Schema. Therefore, within the deployer, a mapping is required between the Python data types and the XML schema data types. This process is known as data binding. Thereafter, with the help of data binding and method annotations, an XML Schema is generated for the Python service. This XML schema together with meta-data pertaining to an Axis Service is given to the Axis2 engine. Axis2 engine creates the WSDL (Web Service Description Language) and thus the Python service will be exposed to the world as a Web service.
The particular solution requires communicating between Python Scripts and Java classes. Jython, which is the implementation of Python programming language in Java, is used to achieve this purpose. It is a programming hybrid. It exhibits the strengths of both its parents, namely, Java and Python. Since Jython is completely written in java, scripts written using Jython will run on top of any compliant Java Virtual Machine (JVM). Jython interpreter will also support many shortcuts, which will enable it to use existing Java libraries.
This architecture identifies two basic actions a SOAP processor should perform; sending and receiving SOAP messages. It provides two pipes (or flows) to perform these two basic actions. These pipes are used for sending and receiving data. The Axis Engine implements these two pipes and these pipes are named In Pipe and Out Pipe. Complex Message Exchange Patterns (MEPs) are constructed by combining these two pipes.
Extensibility of the SOAP processing model is provided through handlers. When a SOAP message is being processed, the handlers that are registered will be executed. These handlers can be registered in global, service, or operation scope and the final handler chain is calculated by combining the handlers from all the scopes.
The handlers act as interceptors and they process parts of the SOAP message and provide add-on services. Usually, handlers work on the SOAP headers, yet, they may access or change the SOAP body as well. When a SOAP message is being sent through the Client API, an Out Pipe activates. The Out Pipe will invoke the handlers and terminate with a Transport Sender that sends the SOAP message to the target endpoint. The SOAP message is received by a Transport Receiver at the target endpoint, which reads the SOAP message and starts the In Pipe. The In Pipe consists of handlers and ends with the Jython Message Receiver, which consumes the SOAP message and hands it over to application.
In a nutshell, the incoming SOAP message is received by the Transport Listener and it is passed through the handler chain. Then, it is given to the Jython Message Receiver, which traverses through the AXIs Object Model (AXIOM) structure and retrieves the required information. AXIOM is the XML infoset model that was developed for Apache Axis2. This retrieved information is passed on to the python service where an AXIOM is created from the returned object. Then, it is sent back, through the handler chain and the Transport Sender, which in turn sends the SOAP message to the SOAP endpoint to which the message was destined to. The process explained above takes place for each and every SOAP message that is exchanged. Axis2 is now able to expose a service written in Python as a Web service.