GSoC: Update

During the development phase, I came across some problems. This is a follow up to my earlier posts. You can have a look at them here.

1) One problem is the way the API is designed to define the XML payload. I designed the WSF/Jython API in such a way that it is comparable with the WSF/Ruby implementation. Therefore WSF/Jython API should adhere to the API specified by WSF/Ruby.

When generating code using Axis2's code generation framework, you should generate it in a such a way that it should support XML object model(preferably in the case of axis2 - apache axiom). Therefore it would be better if the API supported axiom, inorder to use the code generation part. Consider the following example.

from org.wso2.wsf.jython.jythonwsclient import *

req_payload_string = "<deduct><var1>1.8</var1><var2>4.87594</var2></deduct>"
LOG_FILE_NAME = "/home/heshan/IdeaProjects/MRclient/src/python_client.log"
END_POINT = "http://localhost:8070/axis2/services/annotationScript/deduct"

try:
client = WSClient({}, LOG_FILE_NAME)
req_message = WSMessage(req_payload_string, {"to" :END_POINT})
print " Sending OM      : " , req_payload_string
res_message = client.request(req_message)
print " Response Message: " , res_message

except WSFault, e:
e.printStackTrace();

In above code snippet, the payload is set as a string. i.e.

req_payload_string = "<deduct><var1>1.8</var1><var2>4.87594</var2></deduct>"

What should be done is to keep the above feature intact with the API and do a feature addition that will support Apache Axiom.

2) Therefore, the existing WSF/Jython codebase should be modified to support axiom for Jython (should look into this further).

3) Modify the existing codebase to include the code generation part. Having said that there should be more work done to seamlessly integrate this(code-generation part) to WSF/Jython code. More coding have to be done on code generation module for Jython.

4) In a earlier post I said of modifying the Python deployer to support Contract First approach. This happens in the server-side code generation. It's a problem that I am still having.

5) In the same post I said that

0nly generate the client code and use the existing WSF/Jython's client API. Then before running the client code you can add the WSF/Jython client-side jar to the class path.

Now it seems like the best option out of the two options mentioned in the above post.

[The above arguments are my opinions and may subject to change.]