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.

Summer of Codes - Wrapping up

Google Summer of Codes 2009 is reaching its finishing touches. I should thank Google for organizing the event and Abiword for mentoring me. 'Porting Abiword for windows to Unicode', is my project. My focus was, in simpler terms, to provide an Arabic [Unicode] Abiword in Windows. I mean, my testing language was Arabic, thanks to the fact, it is good for the testing of BIDI text.

My mentor dom, the administrator hub, cross-building robsta, the MSVC abicollab and Abiword releases uwog, Windows maintainer sum1, ryanp with documentation and plugins, and msevior... I have to thank these developers for the support they were providing to me and the other participants. A wonderful job, they are doing, at Abiword. By providing a friendly, yet challenging learning environment, Abiword enables us extending our commitment to Abiword.

The Abiword development will not complete with this GSoC - All the successful Abiword students will continue being Abiword Commitors. The next mile stone release 2.8 is the major focus now. Later the SoC codes will be merged from trunk and further modifications will be done. Finally before the merge to the trunk, a merge from trunk to the branch will happen once more to our SoC branches.

It should however be noted, we all prefer not Windows, but FOSS Operating systems (or more specifically, Linux). As a 'cute' word processor, Abiword runs everywhere, literally. So we still feel free to develop for Windows and Mac, when it comes for Abiword. FOSS will rule the world.

"Abiword -- It's cute."

Testing: GSoC2009Unicode

With the assistance of Sum1 and dom, I was able to fix the issue in Preference dialog Language listing. Now I could see all the languages listed, so that I can test the Abiword Unicode Windows Application in Ubuntu/Wine, or Windows in non-latin languages. As mentioned in my proposal, I will use Arabic and Indic Languages for testing. I will be able to fix the bugs in the dialogs more effectively, henceforth.

So I thought of sharing some screeshots, depicting my progress.

Abiword ANSI Windows program in Arabic.


Abiword Unicode Windows program in Arabic. [In Ubuntu/Wine]


Abiword Unicode Windows program in Arabic. [In Windows XP]


Abiword Unicode Windows Preference Dialog in Arabic.




Menubar in Crotian:


After the port, the [non-latin] special characters of the language were displayed properly.