GSoC: Experience

This was my second consecutive year as a Google Summer of Code student. During past 3 months I learned a lot of things. I discussed these in an earlier posts. In a nutshell;

1) I worked with a mentor (Matt Boersma) from a different time zone. This was the first time that I worked with a mentor from a different timezone. Our time difference was nearly 12 hours. We preferred email over chat since it was more conveinent for us.

2) It was a privilege to work as a summer of code student for Python Software Foundation (PSF). All the people who were mentoring me helped me a lot, ranging from shaping up the application (project proposal) to development.

3)It was a greatopportunity for me to work with experienced developers.

I would like to take this opportunity to thank my mentor Matt Boersma and Jython community for helping me to make my project a success. I would also take this opportunity to thank my co-mentors Jim Baker and Frank Wierzbicki.

I would like to state that it was a privilege and a honor to be selected as a GSoC student for a second time and thank Google for organizing a program like this. I am looking forward to participating in next year's GSoC as a mentor. :)

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.]

GSoC: How to integrate with existing code base

This post will contain my arguments on "How to integrate this project to the existing WSF/Jython code base". This is a followup to my last post.

1. Modify the Python deployer to support Contract First approach.

2. To support Contract First approach you need to be able to generate a skeleton and a message receiver for your service. The generic message receiver that I have already written may not work because it works only on a limited schema structure.

3. Another way to look at the above argument(2) may be; only 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.

The above arguments are my opinion(for now) on integrating the gsoc code to existing code base. The above arguments may subject to change.

GSOC: Problems faced during development

Earlier I said that I would be writing a blog post on the problems which I encountered during the development phase of my GSoC project. Here I am compiling them to a list. Some points in the list may not directly be problems but important things which came across during the process.

1. Had a problem with building axis2. This was overcome when I found a workaround for this. (This was a hard issue to regenerate because this will only happen occasionally.)

2. There were lot of dependencies inside axis2's code generation framework. Some dependencies were not set by the build script. Therefore had to manually add the dependencies and run the code. When it gives a compilation error stating a dependency is not there, had to set the dependencies. This took some time :).

3. Had to take some time to understand the existing code base and the architecture of the code generation framework.

4. Learned to work with XSLTs.

5. Another important point to note is that the WSF/Jython distribution, now needs some additional libraries to successfully run. You may have wondered "why is this happening?". As you may already know WSF/Jython is built on top of Apache Axis2. The new releases of Axis2 are having more dependencies towards other liblaries/jars (eg. wsdl4j, etc). Since I no longer work for WSO2, I do not have the access writes to change the build script for WSF/Jython. As soon as I get there, I would remember to revise the build script. Until then you could do a small workaround:)

Download Axis2 standard binary distribution. Then extract it. Add the jars which are residing in the lib folder, to the classpath. Then you could carry on with your work.

6. How to integrate this project to the existing WSF/Jython development. (I will present my arguments on this on a new post)

Design for Jython Extension for Axis2

In a earlier post I said that I am coming up with a Jython extension for Axis2. This will be a code generation tool for jython. This will use existing infrastructure in Axis2 to support Contract First Web services in Jython. What I am planning to do is to integrate this code generation tool into WSF/Jython. Then WSF/Jython will be able to support both, contract-first and code-first approaches. Thus, making the life easier for the Jython developer :).

The code generation engine calls the extensions one by one and then calls a component what is known as the Emitter. Emitter is the actual component that does the significant bit of work in the code generation process. Emitters are usually language dependent and hence one language has one emitter associated with it. Therefore there should be an emitter to support Jython code generation. This simple yet powerful architecture is shown in the above illustration.

The Emitter processes the WSDL and builds a object model. The object model is simply an XML file which contains the object model of the WSDL with respect to Axis2 information model (ie. axis service, axis operation, axis message, etc). The template is a XSLT file which contains information on how the code should be generated. Then the built object model is parsed against the template to build the jython source code.

wsdl2java Code Generation

Axis2's wsdl2java code generation tool can be used to auto-generate programming language code for a given WSDL file. It can either generate code to invoke a Web service, or it can auto-generate the skeleton code that will adhere to the specification described within the WSDL file so that the generated code can be deployed as a Web service.

Axis2 Code Generator

This is a follow up to my earlier post. What I am planning to do is to come up with a mechanism to generate jython code for a given WSDL. For this purpose I am planning to use Axis2's Code Generation module.

When you consider a SOAP processing engine, one of the key value additions will be code generation based on WSDL. It is normally considered as a tool and importance of it can be seen as;

1. User convenience - Code generation tool helps users, to use the framework in easy and efficient way.
2. Make use of the framework to it's full potential.

Now let's have a look at the architecture of Axis2 Code generator.

The tool's architecture is pretty straight forward. The core processes the WSDL and builds a object model. Then the built object model is parsed against the template to build the source code.

Building Axis2

This is a bug (I think) which I came across a couple of times, while building Axis2. To overcome this you have to follow 2 simple instructions ;). For the completeness of this blog post, I will direct you through he complete build process.

1. First checkout the source.

svn co http://svn.apache.org/repos/asf/webservices/axis2/trunk/java

2. Build the project from the source. Do not skip the tests, when you do a fresh build.

mvn clean install

NOTE:

Now is the tricky part. If you are not getting build errors, then no problems at all :). If you start getting build errors related to plugins, then do the following to overcome it.

1. First build the axis2-aar-maven-plugin.

2. Then build the axis2-mar-maven-plugin.

3. Afterwards, build axis2. This should pretty much overcome the build error :).

Jython extension for Apache Axis2

In a earlier post I mentioned that my proposal for GSoC 2009 was accepted. There I didn't give much details on what my project is about. Here is a description of my project.

If you have tried out WSO2 WSF/Jython, you will know that it is based on code-first approach. Web services, is a technology to deliver the architectural style defined in SOA. Although there seems to be a general confusion about the relationship between SOA and Web services, it is important to know that Web services are an implementation methodology that adopts standard protocols to execute SOA. There are two widely used techniques in Web service development, ie.

1. Code First
2. Contract First

With the contract-first approach, the contract for the Web service is determined first and then the supporting tools are used to generate the implementation code. In contrast, in the code-first approach, first the implementation code is created and then the Web service development framework is used to produce the contract for the Web service.

In simpler terms; in WSF/Jython what I am doing is asking you to write the web service and the client. Then based on the service, a WSDL is generated and exposed as a Web service. Afterwards jython client can be used to invoke the service (ie. code-first).

When it comes to contract-first it is vice versa of the above scenario. First we will have to take the provided WSDL in to consideration. Then based on this WSDL, the code should be generated. Following are the advantages of using contract first approach.

• Loose coupling between applications
• Interoperability between multiple services
• Abstraction hides underlying implementation details
• Collaboration and agreement between all parties

Google Summer of Code Accepted Projects Announced

Yesterday I received an email from Google stating that my project proposal for Google Summer of Code 2009 has been selected. I am thrilled of being selected as a GSoC student for Python Software Foundation. I would like to take this oppertunity to thank Jim Baker and Keith Chapman for helping me to iron out my proposal. My mentor for this project will be Matt Boersma. Frank Wierzbicki and Jim Baker will be actively involved in this project as well. I am looking foreward to having a great summer with GSoC.

Google Summer of Code is Back!

Google will be hosting their annual Open Source event this year as well. This will be it's 5th consecutive year. Check out the following video.