GNU Classpath SOAP Summer of Code Proposal

By Andrew Hughes

Project Summary

The GNU Classpath project focuses on the creation of a Free Software[1] clean room implementation of the Java Standard Edition class library[2]. At present, the GNU Classpath code base supports most of the 1.4 API and a majority of the 1.5 API (over 90%) [3].

Part of the proposed 1.6 API will be support for XML-based remote procedure call services, specifically SOAP[5], due to the integration of the JAX-WS specification (Java's Web Service API). As such, GNU Classpath will also need to support this API. The earlier this support is available, the better; GNU Classpath is already playing 'catch-up' against an evolving API.

User Benefits

Users will benefit from this project via the availability of web services support within the Free Java stack (basically a combination of GNU Classpath with a supporting VM e.g. gcj, kaffe, jamvm [6,7,8])


The project is expected to produce an implementation of the parts of the JAX-WS specification that pertain to SOAP. This will include code to represent the APIs, implementation of these APIs and appropriate documentation to accompany this. This implementation will become an integrated part of the GNU Classpath library, in the same way as current support for features such as XML, audio, imaging, Swing, etc.


Broadly, the proposed plan for this project runs as follows:

How much of this is accomplished depends on how the project progresses. It is expected that at least the first two stages will be completed within the allocated time. With just this material being available, the project will still have been worthwhile and provide a basic SOAP implementation. The latter two stages extend on this baseline, but their absence will not be overly detrimental on the project's overall success. At the point of the mid-term evaluation, it is expected that the final end product will be more clearly defined.

Success with respect to the latter three stages can be defined by testing the resulting implementation against existing SOAP implementations using simple clients and servers (e.g. a basic string-passing exercise). The first stage requires comparison against the specified API; ideally, this could be provided by the JAPI tool [3] used by the main Classpath project, but this depends on the availability of alternative implementations to compare against (and primarily on the current progress of Sun's implementation of 1.6).


Why am I suited to work on this project? I am a regular user and developer of Free Software, and have been working with the GNU Classpath project for the last two years. As a result, I have already established myself within the project's development community, with my most recent work being focused on managing the Classpath branch which stablished myself within the project's development community, with my most recent work being focused on managing the Classpath branch which implements the new language features of Java 1.5. The project mentioned here requires this support, and so is also likely to be implemented primarily on this branch.

As to web services, my current academic career focuses on this area to a large degree. As an undergraduate, I wrote a dissertation on the subject and was a joint author on two papers relating to web service composition [9] as part of the Cashew project. The latter also involved implementing a basic SOAP client implementation in Java. My current postgraduate work, hopefully culminating in a PhD, is primarily theory-based, but one of the expected application areas is also in web services. I also remain a member of Cashew [10]. As a result, web services have been a large part of my life for the last three years.

The project appeals to me, both as a way to offer further help to the GNU Classpath project, and also because it gives me a chance to provide a SOAP implementation which is more usable than some of the others I have encountered over the last few years!











Mark's Comments

This application looks good and seems doable. Andrew is already familiar with the project and has discussed some of these ideas already with Chris who has worked on the XML parts of the library (and who I will ask to sign up as co-mentor). Andrew, I think you should be a bit more ambitious and define a more concrete goal/deliverable for the mid-term evaluation (describe what part of stage 2 you can actually deliver if not all of the soap 1.1 implementation). Another thing to make your application a bit stronger is adding a "Challenges" section were you explicitly mention the parts that might be the most difficult to overcome (because they might be outside your actual application work) like the 1.5 language support which isn't complete yet in the rest of the stack, will you need annotation support, what will your course of action be if any of these challenges become a blocker, etc.

ClasspathOpenTasksSOAPSoCProposal (last edited 2006-06-05 19:40:06 by AndrewHughes)