axis-c-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Fremantle <...@hursley.ibm.com>
Subject Re: Is Axis(C++) stable and mature
Date Thu, 07 Oct 2004 11:07:55 GMT
Sanjiva,  Alexei

I think the largest problem we have is 3. I think we once we have 
Samisa's new transport fixed and a MUCH cleaner architecture around 
C/C++ and memory allocation then we will have a solid foundation for 
improvement.
However, let's remember that this is still a very young project compared 
to say Axis Java which is really v3 of that codebase compared to us 
which is really say v0.8!!!

I think it would be good to get to a stable release (maybe 1.4) that 
actually works, and then take a good look at the overall architecture.
We are doing exactly what you have said Alexei... looking at a pure C++ 
engine with clean C wrapping and C++ memory allocation throughout.

Paul


Sanjiva Weerawarana wrote:

>Hi Alexei,
>
>Thanks for your candid reply. We need pointed issues like this to help
>improve
>Axis/C++.
>
>To be fair to Axis/C++, it is indeed a very young product yet. Axis/Java,
>even
>though its labeled 1.2, is actually more like 3.2 .. it inherited experience
>from
>IBM SOAP (let's call that v1) and Apache SOAP (let's call that v2) ... at
>one
>point we actually discussed whether to call Axis v3 directly even. I'm not
>making excuses - Axis/C++ can and should be better, but in reality its still
>quite young.
>
>I accept all your points, except for one:
>
>  
>
>>4) Axis C++ doesn't support ref/href/multiRef that are recommended  for
>>    
>>
>SOAP
>  
>
>>messages and are _default_ at least in Axis Java (that seems to be one of
>>    
>>
>the
>  
>
>>most popular SOAP implementations). This means that interoperability
>>    
>>
>sucks,
>  
>
>>there is a very good chance that you'll not be able to communicate with
>>another side.
>>    
>>
>
>Yes Axis/C++ doesn't do SOAP-ENC stuff fully. IMO that's ok - the WS-I
>profile
>of SOAP only has rpc/literal and document/literal styles .. meaning there
>will
>not be any SOAP encoded graphs coming down the wire if you stick to
>WS-I Basic Profile 1.0 compatible stuff.
>
>Going forward, it is abundantly clear that the world will be much more pure
>doc/lit oriented than even rpc/literal centric. Just look at the new specs,
>the
>trends in toolkits and blogs of various people and you'll see what I mean.
>
>Yes, it would be nice if Axis/C++ were to support href/id stuff. However, I
>don't
>think of that as a big flaw at all.
>
>It is indeed a problem that Axis/Java *still* does multiref serialization by
>default.
>I will start a separate war on that list to change that for 1.2.
>
>Again, thanks for your analysis and please continue to give as much feedback
>as possible. Code contributions are of course welcome too, but solid user
>feedback like yours are critical to the success of open source products.
>
>Sanjiva.
>
>----- Original Message ----- 
>From: "Alexei Dets" <adets@idsk.com>
>To: "Apache AXIS C User List" <axis-c-user@ws.apache.org>
>Sent: Friday, October 01, 2004 10:02 PM
>Subject: Re: Is Axis(C++) stable and mature
>
>
>  
>
>>Hi!
>>On Friday 01 October 2004 05:56, John Hawkins wrote:
>>    
>>
>>>I would like to disagree with that....
>>>
>>>We have four major projects that are using the code as is - we still
>>>      
>>>
>need
>  
>
>>>to make a few additions  - however, they are happy with the results so
>>>      
>>>
>far.
>  
>
>>>Yes, the project needs to include more function - but this will happen.
>>>      
>>>
>If
>  
>
>>>you have specific requirements then please shout and we will do our best
>>>      
>>>
>to
>  
>
>>>accomodate.
>>>      
>>>
>>Axis C++ is not even nearly of production quality at least because of:
>>1) Very active development that causes nearly everyday API and behaviour
>>changes, new bugs and bugfixes etc. - unfortunately Axis C++ has no stable
>>version at all (see below).
>>2) Latest "stable" 1.2 is UNUSABLE for everything except simple demos:
>>transport layer is _completely_ broken and is usually unable to exchange
>>    
>>
>SOAP
>  
>
>>messages bigger than ~2K.
>>3) Axis C++ currently is a mess of C & C++ code. In particular this leads
>>    
>>
>to
>  
>
>>memory allocation/deallocation problems (AFAIK Axis C++ has tons of memory
>>leaks). Also this complicates C++ coding a lot because instead of strings
>>    
>>
>and
>  
>
>>vectors users are forced to deal with plain C data types.
>>4) Axis C++ doesn't support ref/href/multiRef that are recommended  for
>>    
>>
>SOAP
>  
>
>>messages and are _default_ at least in Axis Java (that seems to be one of
>>    
>>
>the
>  
>
>>most popular SOAP implementations). This means that interoperability
>>    
>>
>sucks,
>  
>
>>there is a very good chance that you'll not be able to communicate with
>>another side.
>>5) Axis C++ has problems in the SOAP faults processing.
>>6) Axis C++ has nearly NO documentation. And what it has is partially
>>incorrect.
>>7) Fortunately, Axis C++ developers perfectly understand the main problems
>>    
>>
>of
>  
>
>>the current Axis C++ API & design. Unfortunately, to solve them major
>>    
>>
>rewrite
>  
>
>>is planned that will in turn require user application changes. Probably
>>    
>>
>major
>  
>
>>changes.
>>
>>In the other words - if you are ready to actively _develop_ Axis C++ then
>>    
>>
>may
>  
>
>>be you can use it for some projects. But prepare that this means that your
>>project will not become stable until Axis C++ become stable. So, if you
>>project release date is somewhere around 2006 (or later) you can probably
>>start with Axis C++ now but not otherwise. Axis C++ is very promising but
>>    
>>
>it
>  
>
>>is not mature yet, it is growing and changing.
>>
>>As for me, what I want to see in Axis C++:
>>1) Redesign Axis, implement native C++ API in the whole project. This
>>    
>>
>means
>  
>
>>ONLY new/delete for memory allocations, NO char* etc. C++ (STL) data types
>>instead - string, vector etc.
>>2) Get rid of memory leaks. Probably switching to C++ will help a lot in
>>    
>>
>this.
>  
>
>>Document memory management model in Axis - who, when & how should allocate
>>and deallocate memory.
>>3) Interoperability, more functions, better standards compatibility.
>>ref/href/multiRef as the first priority. Also there are some other
>>interoperability issues.
>>4) _Stable_ release with 1,2 & 3.
>>
>>:-)
>>
>>Alexei
>>
>>    
>>
>
>
>  
>


Mime
View raw message