Link them not~!

I was on the Scientific Linux FAQ, where a strange Q/A hit my eyes.

Q. Why won't you say the name of the commercial enterprise distribution S.L. is built from?

A. That name is trademarked. The easiest way to keep away from all trademark problems, is to completely avoid the name. We believe that most readers are able to figure out which commercial enterprise linux distribution we are talking about.

I found that Scientific Linux was derived from Red Hat Enterprise Linux. I also found the reason for hiding the fact is, to avoid the copyrights issues by violating the Red Hat license, from wikipedia. I later found that once CentOS, another Red Hat derivative had to face some license issues as they have used Red Hat logos in their site. Red Hat had warned CentOS for 'misleading' the users by providing links to Red Hat site in the home page of CentOS. The letter from Red Hat's outside counsel to CentOS can be found here. So think twice before linking some one.

Designing an alternative presentation layer!

My first post on the OGSA-DAI blog, on my GSoC 2010 project, with an introduction to the project, initial design decisions, as well as the Google Summer of Codes updates upto the moment, can be found here.

Commit 994 has become my first commit. Apache CXF 2.2.6 has to be downloaded from here and extracted to "ogsa-dai/third-party/packages/cxf/2.2.6" *** (as the case with the Axis presentation layer). After that, "ant all" from"trunk/presentation/cxf/stubs" will produce ogsadai-4.1-cxf-stubs-1.0.jar. This commit is just for the creation of the stubs jar using CXF, and further commits will follow. After the commit, I have included the module info the  repository structure trac page. The OGSA-DAI nightly tests check the modules by running each night on the server [1].

***
cxf.lib.dir=${packages.dir}/cxf/2.2.6/apache-cxf-2.2.6/lib

cxf.version=2.2.6

Axis specific wsdl (data_request_execution_service_service.wsdl)
<soap:address location="http://localhost:8080/axis/services/DataRequestExecutionService"/>

CXF specific wsdl
<soap:address location="http://localhost:8080/services/DataRequestExecutionService"/>


  <wsdl:import namespace="http://ogsadai.org.uk/namespaces/2007/04/service/execution/bindings" location="data_request_execution_service_bindings.wsdl"/>
  <wsdl:service name="DataRequestExecutionService">
    <wsdl:port name="WSDataRequestExecutionServicePortTypePort" binding="binding:WSDataRequestExecutionServicePortTypeSOAPBinding">
      <soap:address location="http://localhost:8080/services/DataRequestExecutionService"/>
    </wsdl:port>
  </wsdl:service>

Apache CXF seems to be releasing the builds once in a two months. Currently they have released 2.2.8, though I have started with 2.2.6. I have seen many articles on migrating from Apache Axis 1.x to Axis 2. But articles on migrating to CXF from Axis is rare. Though this makes the task more challenging, it has also given me a chance for a research which of course is really cool.

Java WS Core/Final WSRF Migration Guide  describes the code changes of the Java WS Core Framework of Globus Alliance, including WS-Addressing and Faults.

Building the modules using ANT instead of plain java or CXF WSDLToJava alone is interesting and make the task easier, given the fact that we have many wsdls. The below code segments** are for the existing presentation layers, which are removed for cxf at the moment, as CXF comes with support for WS-Addressing 1.0.  (yet to discuss whether to use the CXF libs or the customized ones from globus/ws-addressing as it is for the existing layers). More to analyze the wsdd for the Axis based layer, and I may need to customize the JAXB bindings, as well. 

**
# WS-Addressing
addressing.lib.dir=${dependencies.dir}/globus/ws-addressing/addressing/1.0

[1]  Test Reports 20/05/2010 22:05:50 : daitest

[2] Coding Guidelines

In this post, WSDL code was written using the HTML encoder/decoder provided here.

gsoc-srilanka

The beauty of the Google Summer of Codes is, it never comes on a summer of Sri Lanka. Especially this time, it has come in a heavy rainy days. And parallel to the final semester of our undergraduate studies. It should be noted that Sri Lankan students still enjoy the 'Summer' with Google, and again we reached the list of top 10 as the country.

We recently had the first summer of codes 2010 meetup of Sri Lanka, at the Conference room of the Computer Science & Engineering Department, University of Moratuwa. Head of the department Mrs.Vishaka Nanayakkara, representatives from FOSS.lk, and past and present GSoCers from the university as well as the other universities participated in the meetup, which went fine as an ice breaking session among the GSoCers. We discussed about increasing the participants from the country in the upcoming years. As a coincidence we had also created a google group gsoc-srilanka to promote GSoC in Sri Lanka. Feel free to join, if you are a Sri Lankan GSoCer (Student or mentor) or a FOSS enthusiast.

Mooshabaya 1.0 - RC2

RC2 of Mooshabaya 1.0 with all the primary features implemented is
available now: https://mooshabaya.svn.sourceforge.net/svnroot/mooshabaya/tags/1.0-RC2/

A screencast of Mooshabaya 1.0 - RC2:

Coloring of the nodes hasn't been captured in this screen cast, though Mooshabaya can depict the running workflow dynamically by the colour change as the workflow is run. Similarly the security scenario which has also been  implemented, hasn't been captured in this small screencast. This is a raw screen  capture using XVidCap, which will be mixed with voice and further editing. Avidemux 2.5.2 Multi-platform Video Editor will be used in further editing these raw screen captures. A list of open source video software can be found here.

Commits and Tickets - OGSA-DAI

The tickets assigned to me and my commits to the trunk will be listed here for the documentation purpose.

The tickets for the project.
240, 241, 242,

The important commits.
[This post will be updated as I progress further in my project]

Image: ogsa-dai Axis http://localhost:8080/dai/servlet/AxisServlet