IBM, Marist College, and rSmart would like to work with the Sakai community to get v2.6 operational and supported on WebSphere Application Server and the IBM DB2 database. In the past we have done this on numerous versions of Sakai, but our porting exercise would always begin after the community's GA release. Now that platform portability is a key initiative for the community, we want to work alongside the community on the current release to get WebSphere supported among Sakai's other application servers.
When we did the work to support Websphere with v2.4, it was necessary to make many changes to the sakai code base. We had to create new build scripts, fix some validation errors on xml files, and update java code on about 8 core kernel classes and a bunch of tool classes. Code changes were concentrated mostly on URL redirection and making Sakai XML Parsing non-application-server-specific. We took care to implement these changes in a way that did not affect the existing code from running with Tomcat. The DB2 changes are a little more straightforward.
There is a lot of work to do to get all of these changes into v2.6, especially since we are skipping 2.5 and going right to 2.6. Obviously, 2.6 will be under development when we do this, making it a moving target. We were initially concerned that any newly developed 2.6 code could run the risk of being incompatible with WebSphere and DB2, so we created a webcast that oveviews the portabilitiy issues that we discovered. Hopefully this webcast will be useful for developers and help mitigate any portability issues with new 2.6 code. You can check it out here:
We've also included a document and mp3 file from the Newport Beach session that discussed developing for portability. We will put links to all of this material in this Jira in the near future. Finally, we intend on being more active with testing WebSphere and DB2 during the QA cycle. Marist has created a QA environment for this purpose. Anyone in the community that is interested is invited to help with this.
Working this closely with the community on such an undertaking is going to be a new experience for some of us, and we'd appreciate your thoughts, support, and patience with us as we pick up an oar and start to row. Any suggestions on how to proceed would be greatly appreciated.
Also, if there are members of the community who are interested in working with us to support WebSphere or DB2, there are a few different mechanisms in place at IBM that allow us to provide licenses to members of the community if the tools are used to develop open source code for non-commercial purposes. Please let me know if you might be interested.
Here is the process that we are considering, we'd appreciate your thoughts on how best to proceed:
1. Create 2 new branches of 2.6: WebSphere and DB2. Thanks, Peter, for setting this up for us so soon!
2. Analyze the difference between our WebSphere changes on 2.4 and the current 2.6. Where appropriate, move those code changes into our 2.6 WebSphere branch.
3. Create WebSphere build scripts in our branch, make sure Sakai can be launched in WebSphere while still running perfectly in Tomcat. Note that at this time it is probable that some Sakai tools will not function in WebSphere. However they remain unchanged and will still work fine in Tomcat. We are working to get this step done in the next 2-4 weeks
3. Work the Sakai community process to get this code tested and released to the 2.6 trunk. We want this to occur ASAP so the community will have plenty of time developing and running with it
4. Continue to test with the community's code and fix any existing WebSphere issues with Sakai tools.
5. Work the normal community process to get our DB2 code tested and released into the 2.6 trunk
6. Perform a formal QA of Sakai on WebSphere and DB2 between code freeze and release dates.