Moments with Twitter..

I was recently playing with a few tools, that let you have a look into your past tweets. All My Tweets is an interesting service, that lets you view all your tweets in a simple page, from the beginning. Interestingly, another service, named Twitario gives a view of all your tweets, as a diary. Though Twitario provides a nice interface to find the tweets easily, based on the calendar, it doesn't support Unicode characters, which is surely a minus for those who tweet in Unicode languages. "All My Tweets" include the link to the original tweet itself, where Twitario provides the option to delete the tweets. Having analyzed these tools, I should mention that these tweets were really useful, and brought a few interesting memories back.

Now time to look into the trail of my tweets. Here are some of my tweets, since the 26th of March, 2009.

is finishing the documentation. Mar 26, 2009
It is notable that my first tweet is on documentation. It was probably on the documentation on the project done during the internship. I have always been a supporter of good documentation - It helps the blood flow of open source.

Abiword Cross-compiling using wine successful on Ubuntu. Apr 16, 2009
At that time, uwog was still completing the MSVC build for AbiWord. I found Cross-building useful, since it was complete and gave me a usable AbiWord build for Windows, with no issues. This was indeed a remarkable point, which gave me further confidence to work on AbiWord Windows API, using Ubuntu as my platform.

Summer Love with Abiword... Apr 20, 2009
This was a happy announcement of me getting into the Google Summer of Code 2009. This was my first Google Summer of Code, and I was pretty much excited. AbiWord community was super-friendly, and I am proud to be a member, since then.

with Anjuta.. an IDE similar to Visual Studio... for Linux. May 08, 2009
Anjuta DevStudio is a Gnome Integrated Development Environment. I have mostly used Anjuta as a syntax highlighter for my C/C++ projects including AbiWord development. For compiling and building of AbiWord, I just use make directly.

needs a mute option and filtering for facebook messages. Any suggestions... Jun 01, 2009  
At that time, there was no way to opt-out from the Facebook notifications from the photos that we commented, or to remove ourselves from the facebook threads. I was annoyed, when someone sends group messages directly to inbox. It is great to see that these options are now available for facebook. Now we can remove ourselves from the messages. However, filtering is still not possible. Neither muting (receiving the messages, but not getting the notification of that red one for the new message, for the uninteresting thread).

#AbiWord Turns 11! Happy Birthday to dear Abiword! Happy Birthday to you... Jul 16, 2009
That was remarkable to mark the 11th year of AbiWord, since it started as an open source project in the year 1998.

My computer never complained abt me repeating the same build million times, and I've never complained abt its time delays. We <3 each other. Aug 17, 2009  
Some romance with my computer.. ;)

10 reasons to avoid talking on the phone http://theoatmeal.com/comics/phone from @oatmeal Feb 23, 2010  
Oatmeal never fails to amuse me. Many of its posts deserve a tweet.

my #javascript has gone wild and bigggggg and GO #bananascript GOO.. http://www.bananascript.com/ Compress it.. :) #fb Mar 03, 2010  
Bananascript is a nice online tool to compress javascript files.

A periodic table of visualization methods http://www.visual-literacy.org/periodic_table/periodic_table.html Apr 04, 2010  
Each of these visualization methods deserves a blog post on its own. Visual-Literacy.org provides interesting learning resources, such as an introduction to argumentum. I have also enrolled to their online courses, full of study materials.

I should create some of my own thought experiments as well.. :D http://plato.stanford.edu/entries/thought-experiment/ Jun 06, 2010  
Thought experiments are fun, and it enhances your ability to think, weird. ;) Follow the above link to realize that. Again, each of these thought experiments deserves a post on its own.

GSoC welcome package once more. Special thanks and love OGSA-DAI, OMII-UK and Google. Reminds me the lovable days of GSoC2009 - Abiword too. Jun 19, 2010  
A blog post that happily announces my second welcome package from Google. Yes, this was for my Google Summer of Code with OMII-UK.

Also make sure to read Moments with Twitter - II, the successor of this post.

Building and deploying OGSA-DAI/CXF

Building OGSA-DAI/CXF from Trunk
Check out the source code from the svn using,

svn co  https://ogsa-dai.svn.sourceforge.net/svnroot/ogsa-dai ogsa-dai

Go to the folder ogsa-dai/third-party/packages/cxf/2.4.1 and download and extract cxf distribution into a folder. This will make your CXF home as, ogsa-dai/third-party/packages/cxf/2.4.1/apache-cxf-2.4.1. Here the cxf libs will end up in ogsa-dai/third-party/packages/cxf/2.4.1/apache-cxf-2.4.1/lib. The cxf layer has been tested earlier with Apache CXF-2.2.6 and currently is used with Apache CXF 2.4.1. You might try with the other versions where it gets the directory structure of ogsa-dai/third-party/packages/cxf/{version.number}/apache-cxf-{version.number}. 

Building

ogsa-dai/ogsa-dai/trunk/release-scripts/ogsa-dai/cxf$ ant

This will create the OGSA-DAI/CXF source distribution inside ogsa-dai/trunk/release-scripts/ogsa-dai/cxf/build/ogsadai-4.1-cxf-2.4.1-src and binary distribution is built in ogsa-dai/trunk/release-scripts/ogsa-dai/cxf/build/ogsadai-4.1-cxf-2.4.1-src/build/ogsadai-4.1-cxf-2.4.1-bin. 

Deploying

ogsa-dai/ogsa-dai/trunk/release-scripts/ogsa-dai/cxf/build/ogsadai-4.1-cxf-2.4.1-src/build/ogsadai-4.1-cxf-2.4.1-bin$ ant

The built binary is deployed as directory under the Tomcat container in $CATALINA_HOME/webapps/dai. Pls note that with the later releases of ogsadai and cxf, the version numbers in the respective directory structure too will change. However the directory structure will more or less will stay the same.

After deploying, restart the Tomcat Server. Make sure that ogsadai is deployed correct, by referring to the url http://localhost:8080/dai/services/. Services wsdl's can also be viewed from the services listing of dai in Tomcat.

DataRequestExecutionService

DataResourceInformationService 

DataSinkService

DataSourceService 

RequestManagementService

SessionManagementService

Feb 4, 2011 4:59:13 PM org.apache.catalina.startup.HostConfig deployDirectory
INFO: Deploying web application directory dai
Feb 4, 2011 4:59:18 PM org.apache.cxf.service.factory.ReflectionServiceFactoryBean buildServiceFromClass
INFO: Creating Service {http://ogsadai.org.uk/namespaces/2007/04/service/dataresource/service}DataResourceInformationService from class uk.org.ogsadai.service.cxf.dataresource.WSDataResourceInformationServicePortType
Feb 4, 2011 4:59:19 PM org.apache.cxf.endpoint.ServerImpl initDestination
INFO: Setting the server's publish address to be /DataResourceInformationService
Feb 4, 2011 4:59:19 PM org.apache.cxf.service.factory.ReflectionServiceFactoryBean buildServiceFromClass
INFO: Creating Service {http://ogsadai.org.uk/namespaces/2007/04/service/datasink/service}DataSinkService from class uk.org.ogsadai.service.cxf.datasink.WSDataSinkServicePortType
Feb 4, 2011 4:59:20 PM org.apache.cxf.endpoint.ServerImpl initDestination
INFO: Setting the server's publish address to be /DataSinkService
Feb 4, 2011 4:59:20 PM org.apache.cxf.service.factory.ReflectionServiceFactoryBean buildServiceFromClass
INFO: Creating Service {http://ogsadai.org.uk/namespaces/2007/04/service/datasource/service}DataSourceService from class uk.org.ogsadai.service.cxf.datasource.WSDataSourceServicePortType
Feb 4, 2011 4:59:20 PM org.apache.cxf.endpoint.ServerImpl initDestination
INFO: Setting the server's publish address to be /DataSourceService
Feb 4, 2011 4:59:20 PM org.apache.cxf.service.factory.ReflectionServiceFactoryBean buildServiceFromClass
INFO: Creating Service {http://ogsadai.org.uk/namespaces/2007/04/service/execution/service}DataRequestExecutionService from class uk.org.ogsadai.service.cxf.execution.WSDataRequestExecutionServicePortType
Feb 4, 2011 4:59:20 PM org.apache.cxf.endpoint.ServerImpl initDestination
INFO: Setting the server's publish address to be /DataRequestExecutionService
Feb 4, 2011 4:59:20 PM org.apache.cxf.service.factory.ReflectionServiceFactoryBean buildServiceFromClass
INFO: Creating Service {http://ogsadai.org.uk/namespaces/2007/04/service/request/service}RequestManagementService from class uk.org.ogsadai.service.cxf.request.WSRequestManagementServicePortType
Feb 4, 2011 4:59:20 PM org.apache.cxf.endpoint.ServerImpl initDestination
INFO: Setting the server's publish address to be /RequestManagementService
Feb 4, 2011 4:59:20 PM org.apache.cxf.service.factory.ReflectionServiceFactoryBean buildServiceFromClass
INFO: Creating Service {http://ogsadai.org.uk/namespaces/2007/04/service/session/service}SessionManagementService from class uk.org.ogsadai.service.cxf.session.WSSessionManagementServicePortType
Feb 4, 2011 4:59:21 PM org.apache.cxf.endpoint.ServerImpl initDestination
INFO: Setting the server's publish address to be /SessionManagementService
Feb 4, 2011 4:59:21 PM org.apache.cxf.transport.servlet.CXFServlet updateContext
INFO: Load the bus with application context
Feb 4, 2011 4:59:21 PM org.apache.cxf.transport.servlet.AbstractCXFServlet replaceDestinationFactory
INFO: Servlet transport factory already registered
Feb 4, 2011 4:59:21 PM org.apache.catalina.startup.HostConfig deployDirectory
INFO: Deploying web application directory docs
Feb 4, 2011 4:59:21 PM org.apache.catalina.startup.HostConfig deployDirectory
INFO: Deploying web application directory ROOT
Feb 4, 2011 4:59:21 PM org.apache.catalina.startup.HostConfig deployDirectory
INFO: Deploying web application directory examples
Feb 4, 2011 4:59:22 PM org.apache.coyote.http11.Http11Protocol start
INFO: Starting Coyote HTTP/1.1 on http-8080
Feb 4, 2011 4:59:22 PM org.apache.jk.common.ChannelSocket init
INFO: JK: ajp13 listening on /0.0.0.0:8009
Feb 4, 2011 4:59:22 PM org.apache.jk.server.JkMain start
INFO: Jk running ID=0 time=0/69  config=null
Feb 4, 2011 4:59:22 PM org.apache.catalina.startup.Catalina start
INFO: Server startup in 28740 ms

Deploying Resources - OGSA-DAI/CXF/Linux/Ant/Tomcat/mysql

A random post on deploying the resources. :)

Set an OGSADAI_HOME environment variable

export OGSADAI_HOME=/home/pradeeban/ogsa-dai/ogsa-dai/trunk/release-scripts/ogsa-dai/cxf/build/ogsadai-4.1-cxf-2.2.6-src/build/ogsadai-4.1-cxf-2.2.6-bin

Set the CLASSPATH

cd $OGSADAI_HOME

source setenv.sh

Checking for too long path issue

After setting the environment using setenv.sh, make sure that your classpath hasn't exceeded the maximum allowed length. If it had exceeded, as a quick fix, you can consider moving your OGSADAI_HOME to somewhere upwards towards the root directory.

Creating a sample MySQL database 'ogsadai' using ogsa-dai's createTestMySQLDB class with the table 'littleblackbook' and 10000 entries.

java uk.org.ogsadai.dbcreate.CreateTestMySQLDB -host coal.epcc.ed.ac.uk -port 3306 -database ogsadai -username mysqlUser -password 123456 -rootusername ogsadairootuser -rootpassword ogsadairootpassword

java -cp $CLASSPATH:/home/pradeeban/ogsa-dai/third-party/dependencies/mysql/mysql-connector/5.0.4/mysql-connector-java-5.0.4-bin.jar:/home/pradeeban/gsoc2010/data/build/lib/ogsadai-4.1-sampledata-1.0.jar uk.org.ogsadai.dbcreate.CreateTestMySQLDB -host localhost -port 3306 -database ogsadai -username root -password root -rootusername root -rootpassword root

MySQL Settings:

    MySQLDriverClass:        org.gjt.mm.mysql.Driver

    MySQLHostName:           localhost

    MySQLPortNumber:         3306

    MySQLDatabaseName:       ogsadai

    MySQLUserName:           root

    MySQLPassword:           root

    NameOfTableToCreate:     littleblackbook

    NumberOfRowsToCreate:    10000

    MySQLRootUserName:       root

    MySQLRootPassword:       root

Opening connection to MySQL system database

Creating 'ogsadai' database in MySQL if it does not already exist

Creating user 'root' with password 'root' in MySQL if it does not already exist

User 'root' already exists within MySQL

Dropping table if it already exists

Creating littleblackbook table in database

Preparing insert statement

Adding 10000 entries to 'littleblackbook' .............

Test database created successfully!

Deploying the database to ogsa-dai

DeployResource deployMySQL MySQLResource jdbc:mysql://localhost:3306/ogsadai Login permit MySQLResource ANY
DeployResource deployMySQL MySQLResource jdbc:mysql://localhost:3306/ogsadai Login permit MySQLResource ANY ogsadai root



getVersion method
java -cp $CLASSPATH:/home/pradeeban/gsoc2010/core/client/build/lib/ogsadai-4.1-client-1.0.jar:/home/pradeeban/gsoc2010/core/common/build/lib/ogsadai-4.1-common-1.0.jar:/home/pradeeban/gsoc2010/core/clientserver/build/lib/ogsadai-4.1-clientserver-1.0.jar uk.org.ogsadai.client.toolkit.example.ServerClient -u http://localhost:8080/dai/services/ -c getVersion


java -cp $CLASSPATH:/home/pradeeban/gsoc2010/core/client/build/lib/ogsadai-4.1-client-1.0.jar:/home/pradeeban/gsoc2010/core/common/build/lib/ogsadai-4.1-common-1.0.jar:/home/pradeeban/gsoc2010/core/clientserver/build/lib/ogsadai-4.1-clientserver-1.0.jar uk.org.ogsadai.client.toolkit.example.ServerClient -u http://localhost:8080/dai/services/ -c getVersion

java uk.org.ogsadai.client.toolkit.example.ServerClient -u http://localhost:8080/dai/services/ -c getVersion


How to show the server version
java uk.org.ogsadai.client.toolkit.example.ServerClient -u http://localhost:8080/dai/services/ -c listResources

java -cp $CLASSPATH:/home/pradeeban/gsoc2010/core/client/build/lib/ogsadai-4.1-client-1.0.jar:/home/pradeeban/gsoc2010/core/common/build/lib/ogsadai-4.1-common-1.0.jar:/home/pradeeban/gsoc2010/core/clientserver/build/lib/ogsadai-4.1-clientserver-1.0.jar uk.org.ogsadai.client.toolkit.example.ServerClient -u http://localhost:8080/dai/services/ -c listResources

java -cp client/build/lib/ogsadai-4.1-client-1.0.jar:common/build/lib/ogsadai-4.1-common-1.0.jar:clientserver/build/lib/ogsadai-4.1-clientserver-1.0.jar uk.org.ogsadai.client.toolkit.example.ServerClient -u http://localhost:8080/dai/services/ -c listResources


java -cp client/build/lib/ogsadai-4.1-client-1.0.jar:common/build/lib/ogsadai-4.1-common-1.0.jar:clientserver/build/lib/ogsadai-4.1-clientserver-1.0.jar uk.org.ogsadai.client.toolkit.example.ServerClient -u http://localhost:8080/dai/services/ -r MySQLDataResource -t uk.org.ogsadai.DATA_RESOURCE -c getLifetime


DB Query
pradeeban@pradeeban-laptop:~/ogsa-dai/ogsa-dai/trunk/extensions/basic/client$ ant jar
pradeeban@pradeeban-laptop:~/ogsa-dai/ogsa-dai/trunk/extensions/relational/client$ ant jar

mySQLResourceConfig.txt
DeployResource deployMySQL MySQLResource jdbc:mysql://localhost:3306/ogsadai Login permit MySQLResource ANY
DeployResource deployMySQL MySQLResource jdbc:mysql://localhost:3306/ogsadai Login permit MySQLResource ANY ogsadai root


Deploy the above DeployResource script with:
ant -Dtomcat.dir=$CATALINA_HOME -Dconfig.file=mySQLResourceConfig.txt configure

java -cp /home/pradeeban/ogsa-dai/ogsa-dai/trunk/extensions/relational/client/build/lib/ogsadai-4.1-relational-client-1.0.jar:/home/pradeeban/gsoc2010/core/client/build/lib/ogsadai-4.1-client-1.0.jar:/home/pradeeban/gsoc2010/core/common/build/lib/ogsadai-4.1-common-1.0.jar:/home/pradeeban/gsoc2010/core/clientserver/build/lib/ogsadai-4.1-clientserver-1.0.jar uk.org.ogsadai.client.toolkit.example.SQLClient -u http://localhost:8080/dai/services -d MySQLResource -q "SELECT * FROM littleblackbook WHERE id <  10"
*DRER ID: DataRequestExecutionResource
Data Resource ID: MySQLResource
Base Services URL: http://localhost:8080/dai/services
SQL-Query: SELECT * FROM littleblackbook WHERE id <  10

Wrapping up GSoC 2010

CXF Release Build
After a fix for a missing module in revision 1314, CXF release-build was successful in the test server.

Test Server

Version 1317 and 1318 focused on fixing some bugs in the test code. In 1319,  Base64 tests were done, using org.apache.cxf.common.util.Base64Utilit as the implementation of Base 64 encoding for OGSA-DAI for cxf based layer [1]. The default Base64 implementation of OGSA-DAI is, org.apache.axis.encoding.Base64, as defined in Base64 class of OGSA-DAI.

Base64

Conversion of char[] to string, and mapping the encode and decode methods of Base64Utility, is handled by presentation/cxf/client/src/main/java/uk/org/ogsadai/client/toolkit/presentation/cxf/CXFBase64Mapper.java from the version 1322. This fixes the cxf base64 tests. Further, Base64Mapper interface will be in the core/common module, and  ogsadai.common.Base64 will have method public static synchronized void registerBase64Class(Base64Mapper mapper). Decode encode operations will use the instance of the interface, instead of the implementation itself. After 1322, cxf/server tests depend on the cxf/client module too. Hence adding it as a dependency in ant jarUnitTests for cxf/server in 1323. These changes made all the 13 tests of cxf/server module to run successfully [2], almost completing the development of the CXF - SOAP based layer for OGSA-DAI.

CXF/JAX-WS Layer

With the client toolkit for cxf, the pencils down date reached. Though we will continue with our projects, the changes we did to the code base after 16th of August 1900 UTC will not be counted as work under Google Summer of Code 2010.

ReSTful Layer CXF/JAX-RS

Version 1300 starts the presentation/rest for the ReSTful layer based on CXF/JAX-RS. XXXResource classes define the CRUDs, where the CRUD methods call XXX classes, the classes that calls the lower level implementation further. 1398 becomes the initial implementation of DataRequestExecutionResource for CXF-JAX/RS presentation layer. 

1399 provides a Simple ReST Server implementation. 1402 Lists resources for ReST resource types, while 1403 Gets and Deletes resources with the given resource ids. 1404 Sets the Lifetime, from the Request Service. ReST layer specific exceptions need to be written, and current error handling is very primitive for ReSTful layer.

CXF/JAX-RS Release Script

Commits 1406 and 1407 starts the release script of the ReSTful layer at trunk/release-scripts/ogsa-dai/rest, based on cxf/jax-rs. Needs more changes, and this script is still evolving. This becomes my final commit that comes under Google Summer of Code 2010 (Tonight 1900 UTC was the firm-pencils-down date).

Patches

Patches that cover my contribution towards the timeline can be retrieved by executing the below lines from the trunk.

svn diff -r 994:1407 presentation/cxf > gsoc2010.diff

svn diff -r 1274:1407 presentation/rest > gsoc2010Rest.diff

svn diff -r 1261:1407 release-scripts/ogsa-dai/cxf > gsoc2010Release.diff

svn diff -r 1406:1407 release-scripts/ogsa-dai/rest > gsoc2010ReSTRelease.diff

As the code is committed itself into trunk, the patches is practically not necessary, apart from the Google's requirements or for records.

Modules

Considering the modules, presentation/cxf, presentation/rest, release-scripts/ogsa-dai/cxf, and release-scripts/ogsa-dai/rest contain the code written during this Summer of Code. 1407 becomes the last commit that was done during the Summer, hence the later commits won't be counted for Google Summer of Code. 

The generated tarball of code for the code submission to Google can be downloaded from here.

[1] Base64Utility

[2] Test Reports 04/08/2010 22:08:22 : daitest
[3] OGSA-DAI Team

[4] GSoC2010 Project Hosting for OMII-UK
[5] GSoC2009 Project Hosting for Abiword
[6] Google Summer of Code 2010

Summer of Love 2010 with OGSA-DAI

OGSA-DAI, a name that became the highlight of the year 2010. When we reach the climax of Google Summer of Code, I have to mention that it has become one of the sweetest memories of my 2010. Working with OGSA-DAI team is an amazing experience. We discuss about almost everything over the irc. It varies from Web Services to Neural Networks, Sri Lankan tea to Colombian Coffee, and Databases to Grid Computing. Apart from the scope of the Summer of Code project, I am pretty sure that Michal (my GSoC 2010 mate in OGSA-DAI) and I were able to gain a considerable amount of knowledge on OGSA-DAI as well as the technologies that are used. The super-friendly environment of OGSA-DAI team is one of the best learning platforms that I have experienced, During the last few months, while working with the presentation layers, I was also able to play with the code base, and experiment with it. 

Developing a presentation layer for OGSA-DAI is a challenging, but an interesting task to do. I started to write an article on how to write a presentation layer for OGSA-DAI, soon after I completed developing the SOAP based layer, which I later found more SOAP and CXF biased, when I started working with the ReSTful layer, which made me postpone releasing the article, as it obviously needs further modification. Officially Google Summer of Code completes by tomorrow, and of course, that just completes the direct involvement of Google. After taking a short break for my final exams, I will be back to OGSA-DAI on 6th of September. A compatible community is always a great motivation for a FOSS developer. With a strong community, OGSA-DAI becomes an ideal project for someone who is passionate on Software Development. 

At this moment, I should thank my mentors Ally Hume and Bartosz Dobrzelecki for the great support and motivation they offered throughout the project. My Special thanks goes to Mario Antonioletti for his constructive thoughts and help when I first applied to GSoC, as well as his encouragement throughout the project timeline. My sincere thanks to Mike Jackson for providing help in setting up the tests and release builds in the server, effectively managing the project. I should also thank Neil Chue Hong for administrating Google Summer of Code this year, providing updates and assistance to students and mentors from OMII-UK. Thoughts of the core team members Charaka Palansuriya, Carlos Buil Aranda, Tilaye Alemu, and Amy Krause were always fascinating and highly motivating, and the OGSA-DAI family is really a nice environment to work with. OGSA-DAI is a team with strong bonds, and we all love the cute hexapus!

OGSA-DAI ~Presenting in CXF~ (4)

Build Scripts - Release Builds

Build files and CXF web.xml for the release build of OGSA-DAI/CXF/JAX-WS are committed in the revision 1273. 1281 adds Spring aop (Aspect Oriented Programming) as a dependency for cxf/server module.

OGSA-DAI/CXF deployed in Tomcat

More modifications in the release script, towards deploying in Tomcat (currently testing with Apache Tomcat 6.0.24) are done in the revisions 1282 and 1283. Listing all the 6 OGSA-DAI (SOAP) Services in http://localhost:8080/dai/services. The functionality provided by the package uk.org.ogsadai.rest.files will be handled more for CXF layers here.

OGSA-DAI SOAP Services along with the operations are tabulated here (in DOC format  and PDF format). These tables are drawn from the service listing of OGSA-DAI deployed in Tomcat (refer to the images).

ogsa-dai/trunk/presentation/rest

1274 - ReSTful Presentation Layer code development based on JAX-RS/CXF. Committed the folder.

Testing

1277 is a minor fix that adds log4j as a dependency in the cxf/server module build, which fixed the odd java fork failure in the test framework, due to the Logger class not found exception [1],[2].

Fixes to Base64 Tests will follow.
Todo
Details of CXF based layer to be added here.

[1] Test Results (Currently) [2] Test Framework

Mid evaluations with the cute hexapus!

Mid evaluation is on the way today evening, while we have done the initial design of ReSTful presentation layer, and towards the completion of the SOAP based layer. Web Application Description Language (WADL), which is said to be the ReST equivalent to WSDL of SOAP, paired with JAX-RS supported by CXF will serve us in this. WADL2Java tool for the stub generation is worth mentioning here. Service Oriented Architecture (SOA) and Resource Oriented Architecture (ROA) all sound good. Again feeling the need for a wsdl2wadl tool [1] (and a wadl2wsdl ;)).

WADL is becoming the standard (if not already) for REST as WSDL for SOAP, though REST with WSDL2.0 too is possible. "CXF JAX-RS now supports the auto-generation of WADL for JAX-RS endpoints. [2]" I was initially planning to write WADL on my own, by referring to the respective WSDL (and then use wadl2java for the stub generation). Finally felt auto-generation from JAX-RS is a smarter option, where we start from Java to WADL and after fine tuning the WADL that is auto-generated from the JAX-RS endpoints, going back to the java code using wadl2java (as thought initially).

[1] "Modelling Web-Oriented Architectures", by G.Thies and G.Vossen

[2] CXF JAX-RS (JSR-311)
[3] SOAP examples for ogsa-dai.

[4] SOAPUI - Working with REST Services. 
[5] #rest on irc.freenode.net
[6] wadl2java  
[7] MYEclipse - Developing REST Web Services Tutorial
[8] Chapter 13. How requests (workflows) are executed
[9] OGSA-DAI 4.0 Axis Documentation
[10] The Client Toolkit Tutorial
[11] JAX-RS (JSR-311)

 * Hexapus refers to the logo of ogsa-dai.

OGSA-DAI ~Presenting in CXF~ (3)

Resource Oriented Architecture
While focusing on the SOAP based layer implementation, we also had the first formal discussion on the design of ReSTful presentation layer, this week. I was able to join the discussion via skype, and took down notes, which were also summarized to the committer list by my mentor Ally Hume.

More development
When considering the implementation and the commits, commit 1232 is CXFServer, which is the access point of OGSA-DAI service/resource proxies for OGSA-DAI CXF services. client/toolkit/presentation/cxf/CXFResource.java - A place for the client side resources, is committed in 1244, which is still being modified. CXF implementation of DataRequestExecutionResource, CXFDataSinkResource, and CXFDataSourceResource are committed in the revisions 1245, 1247, and 1248 respectively.

Builds
1250 is literally an insignificant. But I couldn't resist committing this, as I am 'worried' to see the cxf/client module being broken at the test server. So let it build happily till the complete fix is committed, which makes all sub-modules of the module presentation being built without any issue. During this period, I also refactored the code to have column width of 80, to fit the ogsa-dai coding standard. My usual column width was 120. 1261 becomes the first commit towards the cxf binary release, by including the ogsa-dai/cxf release script. Building the source.zip distribution is fine. Deploying to Tomcat from the binary.zip that is built, still need to be fixed, obviously. Commit 1263 uncomments the cxf/server module from the trunk's build, as it is not failing anymore.

OGSA-DAI and ROA

OGSA-DAI, by nature can be exposed as resources, and it fits the ReSTful design pretty well, and the initiatives to an alternative ReSTful layer was taken a few months ago. Since the inclusion of the ReSTful layer as a goal of a GSoC project of OGSA-DAI, the design discussions started accelerating.

The first formal discussion on the design was held on 1st of July at Edinburgh Parallel Computing Centre (EPCC), by the senior architects Ally and Bartek. The discussion was targeted towards a high level description of the ReSTful layer design.

OGSA-DAI ~Presenting in CXF~ (2)

During this week I have been working on the server module, and committed them with the unit tests, though some more commits are remaining.

CXF-Compliant implementation of OGSA-DAI WS-EPR resolver portType operations is done in the commit 1189. Unit tests for the server module - 1190 becomes the first commit on the tests. Removed NStoPkgProperties from the build file, as it is irrelevant for CXF stub generation. in the commit 1205. As of the commit 1206 - which commits the files of the server module, the server module is fixed with some todos left.

After completing the client module and testing, will have to start implementing the Resource Oritented Architecture - Exposing the services as resources and the ReSTful presentation layer utilizing JAX-RS implementation of CXF. We decided to start discussions and design of the ReSTful layer, by mid of this week parallel to the SOAP based layer, as that will make the timeline more efficient.

I got the welcome package on June  19th - 2 Stickers, a pen, and a note book, along with the card. Special Thanks - OGSA-DAI, OMII-UK, and Google.

OGSA-DAI ~Presenting in CXF~

Coding has started to accelerate. Revision 1065 customizes the built-in JAXB mapping, by an external binding file. This changes the default mapping of xs:dateTime from XMLGregorianCalendar to java.util.Calendar. For the ease of further commits, I added the respective client and server implementation folder structure in the commit 1066 along with the utility class CXFUtils.

1069 extends the Request Status Builder for the cxf client. 1070 includes the utility methods for handling the exceptions for the client toolkit. 1076 was an interesting  [ ;) ] fix, which fixes some years which I overlooked.

As with the common case of CXF stub generation, Lists are generated instead of arrays.
An example is,
-  final DataType[] inputData = inputBean.getInputLiteral();
+  final DataType[] inputData = inputBean.getInputLiteral().toArray(new DataType[inputBean.getInputLiteral().size()]);

 -              inputType.setInputLiteral(mCurrentData.getDataTypeArray());
+           inputType.getInputLiteral().clear();
+           inputType.getInputLiteral().addAll(Arrays.asList(mCurrentData.getDataTypeArray()));

1093 fixes some issues in an earlier commit related to this.

1094 and 1095 includes the CXF compliant Request management and Session Management Services respectively. 1096 is the CXF implementation of  the WS-ResourceLifetime portType operations.

1118 includes classes in execution/workflows. 

Classes in execution/Worflows.

Considerable changes in the stub generation includes,
(1) Inner class InputsType.Input replaces the class InputsTypeInput.

(2) Getters of the list returns a reference to the live list, not a snapshot. Hence to an item, getOutputStream().add(newItem);

from the method  public List getOutputStream() in OutputsType class.

(3) Regarding the generated fault types, in case of Axis, it was in the format of XXXType from the stub which needed to be used in the code, in cxf stubs, we have XXXTypes associated with XXX, where XXX from the stub is used in the code. [XXX denotes the faults.]

These changes in the stub code are reflected in the respective server side code.

1119 - The CXF implementation of Request Builder implementation. 1122, handles the AddressingUtils, which parses the SOAP Message Header.

@WebServiceProvider
public class AddressingUtils
{
....
    @Resource
    private static WebServiceContext context;


        SOAPMessageContext soapMsgContext = (SOAPMessageContext) context.getMessageContext();
        SOAPEnvelope envelope = soapMsgContext.getMessage().getSOAPPart().getEnvelope();

Commit 1128 defines CXF_MESSAGE_CONTEXT_ERROR. Commits 1144, 1154, and 1173 are for the cxf compliant data sink service, execution, and data resource information services, while 1161 and 1162 implement the data source and intrinsics  portType operations. 1159 is for the initialization class for CXF-compliant presentation layers, which is being modified at the moment. 1172 does some minor fixes in the exceptions thrown.

OGSA-DAI - Coding with enthusiasm

As summer of codes officially started, I did my second commit on May 26th midnight (Sri Lankan time). In this commit, I have created the build and properties files of the client and server module. And wow, this commit has become the 1000th commit of OGSA-DAI. As an open source project OGSA-DAI has reached many mile stones and success stories in a relatively short period. Though we, GSoCers develop remotely from the mentors and the other developers, the super-friendly private/developer irc of OGSA-DAI always gives us the feeling of working in the same environment as the other developers  are.

1026 and 1030 became my third and fourth commits respectively, where 1026 was a minor fix on the wsdls, while 1030 fixed the namespace to package mapping based on the cxf -p option in the build.xml, which was handled by NStoPkg.properties in the Axis presentation layer. Currently I am in the process of developing the client and the server, which will either be committed to the trunk as a huge commit or a huge list of tiny commits, in the upcoming week.

To get the patches of my progress so far, use the below command from ogsadai_home/presentation;
svn diff -r 994:${current} cxf > gsoc2010.diff
svn diff -r 1274:${current} rest > gsoc2010Rest.diff
svn diff -r 1261:${current} ../release-scripts/ogsa-dai/cxf > gsoc2010Release.diff
svn diff -r 1406:${current} ../release-scripts/ogsa-dai/rest > gsoc2010ReSTRelease.diff

or for Release Script, from ogsa-dai/trunk/release-scripts/ogsa-dai/
svn diff -r 1261:${current} cxf > gsoc2010Release.diff

gsoc2010.diff refers to the cxf/soap based layer patch, while gsoc2010Rest.diff refers to the ReSTful layer, where gsoc2010Release.diff refers to the release script.

GSoC with OMII-UK

Google Summer of Codes officially begins today with so much of excitement, and the students have already started their development. One more energetic summer with OMII-UK has begun with 4 students, this time. As with 2008 and 2009, this summer too projects have been chosen from the set of projects under OMII-UK. Apart from Michal and Pradeeban from the OGSA-DAI team, two more students each from Rapid and SAGA teams, make the list of participants mentored by projects under OMII-UK this time.

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.

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

Timeline: Community Bonding

April 26th 1900 UTC the names of the accepted projects were announced, and the community bonding period began. Since I have been given svn, blog [1], and the wiki [2] access on 30th of April, I wrote down the timeline in a wiki page of OGSA-DAI. I will record the further project progress and decisions in the ogsa-dai wiki. Tickets will be created for each task that is specified in my proposal using Trac - an enhanced wiki and issue tracking system, used by ogsa-dai project, which I will mark as resolved with the progress.

[1] OGSA-DAI Blog
[2] AlternativePresentationLayers 
[3] REST in OGSA-DAI
[4] The Java API for RESTful Web Services
[5] Governance Model 
[6] Part VI. OGSA-DAI for server developers
[7] Part II. Getting Started
[8] Coding Guidelines - OGSA-DAI

gsoc2010OgsaDaiPres

It's really exciting to start working with Google Summer of Codes for the second time. I had an interest in applying for OMII even for my GSoC 2009, as mentioned in the post "my summer of codes so far" since Taverna and OGSA matched my experience during the internship, where I later applied for Abiword due to my personal interest in Abiword and the project. So this time I didn't have to spend much time to choose OMII and particularly OGSA-DAI. 

After a considerable amount of research myself, and with the assistance of the OMII developers for OGSA-DAI project, Mr.Bartosz Dobrzelecki (bartek) and Dr.Mario Antonioletti (mario) from the University of Edinburgh, I applied for the project "Alternative presentation layers for OGSA-DAI" on 8th of April, where the application deadline was on 9th of April.

I was given access to the ogsa-dai private developer irc on 15th of April, as well as Michal - the candidate for the project "Re-implementation of the OGSA-DAI Distributed Query Processor in Clojure." This has given us an opportunity to interact with the developers well before the "Community Bonding Period" which begins on 26th of April, along with the official announcement of the successful applicants.

OGSA-DAI can be checked out from its svn location. svn co https://ogsa-dai.svn.sourceforge.net/svnroot/ogsa-dai/ My code will be committed to the trunk ogsa-dai/trunk/presentation/cxf. The presentation layer code stays in ogsa-dai/trunk/presentation/, where WSDLs are inside the folder wsdl and the currrent axis presentation layer is inside the folder axis. Hoping a Summer of Love with OMII/OGSA-DAI starting in a very few days, with the hope that University of Moratuwa will lead the GSoC participant count for the forth time (2007 - 22, 2008 - 24, and 2009 -22). Hope to keep blogging my progress on the project here.

[GSoC 2010] Alternative Presentation Layer for OGSA-DAI

Having the vision of sharing data resources to enable collaboration, Open Grid Services Architecture Data Access and Integration (OGSA-DAI) provides access, transformation, integration, and delivery of data. It supports Apache Axis 1.4 and Globus Toolkit (gt-4.2), available to download for both the two platforms.
 
Under Open Middleware Infrastructure Institute (OMII-UK), an alternative presentation layer using Apache CXF instead of the outdated Axis which is currently used, is discussed as a project for Google Summer of Codes 2010, which I found very interesting for this summer.  

Project Proposal

Project Mentor: Ally Hume

OGSA-DAI has a layered architecture consists of the data layer, business logic layer, presentation layer, and client layer, when considering the architecture in bottom-up. Presentation layer encapsulates the required functionalities to expose the data service resources using the web service interfaces. Presentation layer currently consists of two realization, where each of them have  a WSDL that describes the interface. 

Both the realizations are compliant with Web Services Resource Framework (WSRF), and communicate with the respective client stubs using SOAP over HTTP. Hence design and implementation of an alternative RESTful presentation layer using CXF JAX-RS (The Java API for RESTful Web Services) is also included in this project, as it will be lightweight and best for bespoke clients.

This seems an interesting initiative as the performance and the simplicity will be highly improved. I have seen reasonable comparison of Axis 2 and CXF [1], [2], though they must be outdated by this time.

[1] Technical Notes on OGSA-DAI
[2] Resource on writing a presentation layer
[3] OGSA-DAI Tutorial
[4] FAQ: OGSA-DAI WSI-specific (Based on Axis 1.4 web service stack)
[5] FAQ: OGSA-DAI WSRF-specific (Based on the globus toolkit)
[6] General FAQ
[7] Known Problems
[8] Binary Transfer Benchmarks 
[9] GSoC 2010 Announcement in OGSA-DAI blog
[10] Google Summer of Code 2010 site