Feeds:
Posts
Comments

Archive for April, 2008

There is this new implementation of Reliable Messaging from WSO2 called Mercury. You can download it from here. There is discussion going on as to whether Mercury should be sequal to Sandesha2 as Sandesha3 or not. Ppl who argue against it has basically following points

1. When adding features to current Mercury it will ultimately become as complex and as ugly as Sandesha2. In other words they have concerns whether Mercury solve existing Sandesha2 problems.

2. Sandesha2 is tested for performance and results are satisfactory and have doubt about Mercury performance.

3. Sandesha2 is feature rich.

4. Mercury still only provides only a very basic feature set and therefore they can’t adopt it at this stage.(RM 1.1 spec is not supported)

What those ppl accept in general is that

Sandeha2 is complex and need lot of improvement and that improving is not easy.

Ppl who argue in favour in Mercury have following points

1. Mercury architecture is based on a state model which is clean.

2. It would not be susceptible for race conditions and dead locks(I heard some ppl worry about that in Sandesha2)

3. Mercury is open for improvements and they beleive that it could be done in a cleanly fasion.

I am these days considering implementing Mercury/C for Axis2/C web services platform. When I had an initial look at the architecture diagrams and Mercury/Java code I understand that it is actually very clean and easy to adopt for writing Mercury/C, although I am not satisfied with the quality of the architecture documents that shipped with the Mercury release. It seems that nobody has reviewed it. For example it mention CSR but nowhere it has defined what is CSR(Of course Create Sequence Response). I must thank Amila Suriarachchi for coming up with this innovative design. I will continue to analyse Mercury architecture and most probably  will implement Mercury/C  which  I beleive could be completed in about 3 months time once started.

Advertisements

Read Full Post »

WSF/C Hackathon

For the past two and half years we developers at WSO2 were busy working on to add more and more features to WSF/C framework with the help of the community. After two years we can be happy with what we have acheived so far. WSF/C is now a feature rich, stable web services framework which also is the base for WSF/PHP, WSF/C++, WSF/Perl and WSF/Ruby. So it is the time to lookback and to see what we can do more to improve WSF/C. So the developers at WSO2 got together and discussed and worked on a plan to concentrate on the following.

– Improve the code quaulity by adding appropriate code comments, adding more descriptive loggings and reviewing the places where importand and/or complex logic involved.

– Get rid of the heaped junk here and there.

– Understand if we have missed anything.

– Identify any need for api changes that would lead to a next major release.

We started on doing this first on Axis2/C, the web services core of WSF/C and then plan to continue this on Rampart/C, Sandesha2/C, Savan/C and wsclient.

After two weeks of initial involvement it is the time for look back and evaluate the progress. Personally I’m quite satisfied about the progress. I consider this as a great opportunity to turn back and look at my own code on Axis2/C, a task I could not do for most of the time because of other involvements of adding more features.

There are basically two major paths a software can be developed.

1. Start developing the actual software after a rigorous and comprehensive architectural designs and discussions that involve software architects, users, developers etc. The design phase usually supposed to be comparatively longer than actual developement and by the time the design come to the developer, he has very descriptive details on how to proceed with the development. This is the model that is followed in most of the large scale software development companies in Sri Lanka. The life of the developer is very easy if everything goes as planned and if architectures involved are extrememely experienced and talented so that they could forsee what is going to be developed in exact details correctly.

2. Work in a kind of iterative development method where developer initiate the work and he uses his every ingenuity to achieve the final goal. He always have something working and continue on adding to it until it grows. Sometimes in the process he need to get rid of complete iterations that fails but provides direction for correct path. This often leads to very good quality software. But the success of this method relies greatly on the ablity and creativity of the developer.

What I believe is a hybrid of the above two to overcome the cons of both approaches.

I believe WSFC/Hackathon like sesssions constitute a greater part in a hybrid process like above.

Read Full Post »

As I have promised earlier I have written two articles on wso2 wsclient and amazoneclient. wsclient is a wget like command line tool which is designed to consume web services from command line. Today I added the capability to add custom soap headers by using the new option –soap-header LINE. This new option makes wsclient much more powerful tool since you can add ws* capablities through custom soap headers.

amazoneclient is also a command line tool which internaly use wsclient. This tool can be used to do online transactions with Amazon E-Commerce web services. These days I’m working on a WSO2 solutions demo site which is aimed to demonstrate the power of WSO2 WSF/C web services platform through some solutions. amazoneclient will be the first solution published on this site. This site will be launched within couple of weeks.

The articles are Calling Web Services from the Shell and Amazon ECommerce Client

Read Full Post »

In an earlier blog I emphasized the importance of having a developer guide for Axis2/C internals. I think a new article Overcoming Memory Related Issues in Axis2/C published in Wso2 Oxygen Tank by Manjula Peiris is a step towards that direction.

Read Full Post »

Useful Axis2/C web services links

Read Full Post »