Axis2/C, default HTTP transport should be libcurl based.

Apache Axis2/C is the only complete SOAP engine, which is comply with most number of WS-* specifications, inter operate with Axis2/Java, .Net and other implementations and available in C. However still I could see, there is some room for improvement. One thing we could consider is using libcurl based transport implementation as default HTTP transport implementation. Using libcurl is important because of the number of reasons.

First reason I would like to emphasis is , In Apache Axis2/C we are going to implement worlds best SOAP engine which could interoperate with other implementation and ported into other applications. It may be an over estimation , but at least as an Axis2/C developer I should aim for it therefore wasting our energy on HTTP transport implementation is not good. I see it as a waste since it is a deviation from our main target. Allocating our resources on (Axis2/C developers) HTTP transport implementation should be minimal. On the other hand HTTP is only one transport, though it is the most important transport.

Second reason , I claim we should move to libcurl based transport is , libcurl is one of most neat and complete HTTP transport implementation availabe for C. Unlike languages such as Java, PHP and Ruby, C is not privileged to have hundreds of implementation to available.It happens because of various reasons. Those reasons are not relevant to this post. However in this case we have the best option in our hand.

Other reason I believe we should go for libcurl transport is , it has implemented HTTP transport and some other transports in quite handy way [link]. Because of the WS-* Vs REST war, we are aligned to give features more RESTFul way. Therefore we have a requirement of complete HTTP implementation badly. Although we managed to get implemented what we want, time to time we need to have extra features in HTTP implementation. For an example , WSF/PHP has such a requirement [link] which can be served in WSF/C or Axis2/C pretty easily with libcurl based HTTP transport. In the long run , having complete HTTP implementation as libcurl in hand will be a smart decision.

We could move to libcurl based transport implementation easily since it's license is Apache2.0 license compatible one. libcurl uses MIT/X derived license which is recognized as Authorized license [link]. Someday if we come across a dependency problem with users, my understanding is we could ship libcurl in source or binary format with Apache Axis2/C. If I miss some point here please feel free to correct.

As an Apache Axis2/C developer, I should say our main target is ability to be being binded and ported. It may be scripting language, mobile application, embedded application or what ever you say. Here [link] libcurl provide evidence for its abilities. When we go for bindings , I think we could get that language binding support or we could map it from C layer to that language. I believe this as one important reason for go for libcurl transport.

In the point of enterprise users and for production environment there is curl professional support is available [link]. In the case of requirement of fast and dedicated help, users will be able to go for it. Although I do not have marketing intension here. I think, it is some thing (professional support) some users will consider.

As we always do we can learn from Apache Axis2 Java implementation here. They are using Apache HTTP Components [link] for their HTTP requirements. I do not think they have any problem with using that library over having their own HTTP implementation.

Final point I would like to make for, move to libcurl transport is , not to offense but to admit that we have some problems with existing HTTP transport implementation. Yes, we are working and will be able to fix them soon. But why bother? while we having good implementation available. One could argue that when we have one our own implementation we have 100% control over it. However in any project we could not have such a guarantee. There is a good chance that developer might left the company or project. Therefore without good documentation and knowledge transfer others might happen to shoot blindfold some time. Therefore it is safe to use something widely adopted and well documented.

In conclusion, because of the reasons like libcurl is complete HTTP implementation, we need only little effort to integrate it to Apache Axis2/C, libcurl license is compatible with Apache2.0 license, libcurl carries many bindings and it is very portable. I think Apache Axis2/C should move to libcurl based HTTP transport implementation as it's default transport implementation and it should do it near future.

Share and Enjoy:

Senaka 1.14.08 / 8am

Hi Dinesh,
I see you have a valid point here.

1. CURL License is Apache Compatible. We can ship CURL with our binaries, according to their license.

2. CURL does lot more than our transport.

3. CURL has a dedicated workforce.

But, However,

I personally believe it is better to have our own transport implementation as the primary choice and to have the CURL-based transport as the alternate for additional features. Therefore, if a user wants something, we can implement it in our transport if it is trivial or simply get it done with CURL if it is hard. This way, we are not dependent on CURL.

Regards,
Senaka

admin 1.14.08 / 9am

Senaka,
AFAIK, in terms of HTTP transport libcurl has implemented almost everything. If user wants something related to HTTP we could always get it from libcurl I guess, and if we need to get something done in libcurl we can provide patch for them. Whereas if user needs something that is not related to HTTP, it is something else not HTTP

Odi 1.14.08 / 11am

I am not a C expert. But I have worked on the Apache HttpClient. All advice I can give you is: use libcurl. Don’t bother with your own implementation. I would go as far as deprecate your own and remove it in the next major release.
HTTP seems simple at first, but believe me, it is not what it looks like. There are many nasty details. For instance the testing against real-world servers is not a trivial task, and not something that can easily be done in a test suite. It’s hard not to break interoperability! It took the HttpClient team 3 major releases and about 10 core developers and many years to come up with an implementation that merits the term “good”. Now in its upcoming 4th incarnation we finally have all the knowledge (learned the hard way) that we were able to rebuild it right from the ground up (resolving architectural defficencies). Having a good HTTP implementation ready to use is so important because it saves you a lot of trouble and coding resources. libcurl has been used in many many applications, so you can expect very good stability and feature completeness. Roling your own implementation is just a waste of resources. Better ignore those usual NIH moaners.

Davanum Srinivas 1.14.08 / 7pm

why the late realization? guess, better later than never. This is *exactly* why i pushed so hard to get Axis2/Java to use Commons HTTP Client

Senaka 1.14.08 / 9pm

Odi, Dinesh,

I strongly disagree with the point that CURL is the 1st choice. Samisa has clearly explained this in his e-mail to the WSF/C Dev List [1]. I believe we should be having any dependencies along our path. Deprecating our code is a mere underestimation of people who worked for it. We could have re-implemented a CURL II if we had enough time and workforce, but, it is not possible as Axis2/C does not only focus on transport and HTTP.

But, if we are to support something advanced, which needs lots of effort, as,
1. Implementing NTLM Authentication
2. Implementing Session Support
I believe it is better to use CURL to get the job done. Thus, CURL should always be our alternate.

[1] http://wso2.org/mailarchive/wsf-c-dev/2008-January/003101.html

Hi again,
Please correct my line “I believe we should be having any dependencies along our path” to “I believe we shouldn’t be having any dependencies along our path” in the previous reply.

dinesh 1.15.08 / 7pm

Senaka,

Not to offense, but in the reply to wsf-c-dev Samisa didn’t explain anything, at least he didn’t read this post. I guess, he doesn’t know what is in here. He just explained his point of view. I still think there isn’t any problem for porting to scripting languages. I agree, additional dependency might be a problem, but that is the cost we have to pay for doing right thing.

Senaka, I think you get my point wrong. I strongly disagree with you regarding underestimating work people who worked for Axis2/C HTTP transport. I just wanted to make it right. If community don’t agree , lets forget about it. No worries

I quote one of your point here.

“We could have re-implemented a CURL II if we had enough time and workforce, but, it is not possible as Axis2/C does not only focus on transport and HTTP”

That’s the exact point, why we need to use libcurl, let the professionals to do their job.

Senaka 1.20.08 / 8am

Hi Dinesh,

Well I believe it is better that we get started with improving the CURL based transport in Axis2/C. I guess this would make CURL the 1st choice due to it’s higher support, even though I personally disagree. I think it is ok to have a similar scenario as Guththila and libxml2. However, I strongly oppose anybody who would deprecate the current transport implementation.

As you say, CURL wont affect scripting languages, it would only affect mobile platforms where the smaller size is preferred over greater support.

Also, we must not lock ourselves to the limits of CURL. If CURL is not customizable enough we’d rather implement it on our transport. This would give our users more flexibility.

We also, must not stop working on our transport implementation. There may be users who’d prefer only to use apache licensed products, whereas CURL is not. This can be a reason as now Apache 2.0 is GPL compatible with GPLv3, where as CURL is not.

Regards,
Senaka.

dinesh 1.21.08 / 7am

Hi Senaka,
CURL is shipped under MIT derived license which is Apache2.0 license compatible [1]. Users who prefer to use apache 2.0 compatible licenses can have CURL without any problem. If you are talking about GPL compatibility, CURL doesn’t have any problem because MIT license is also GPL compatible [2].

1.http://people.apache.org/~cliffs/3party.html#category-a
2.http://en.wikipedia.org/wiki/MIT_license

daniel.haxx.se » Axis2/C going libcurl? 5.24.08 / 12pm

[...] considering to move over to use libcurl for HTTP transport by default. At least Axis2/C developer Dinesh Premalal thinks they should, and he lists multiple reasons in his blog and I can of course do nothing but [...]

Dinesh’s Web Log

Axis2/C, default HTTP transport should be libcurl based.

10 Comments

Have your say

About

Recently

Categories