You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-user@axis.apache.org by John Hawkins <HA...@uk.ibm.com> on 2004/10/01 11:56:34 UTC
Re: Is Axis(C++) stable and mature
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.
cheers,
John.
John Hawkins
hsong@invatron.co
m
To
30/09/2004 19:44 "Apache AXIS C User List"
<ax...@ws.apache.org>
cc
Please respond to
"Apache AXIS C Subject
User List" Re: Is Axis(C++) stable and mature
Thanks, Alexei
Hailu Song
Software Developer
Phone: (905) 282-1290x249
Fax: (905) 282-1266
email: hsong@invatron.com
Alexei Dets
<ad...@idsk.com> To: "Apache AXIS C User
List" <ax...@ws.apache.org>
cc:
09/30/2004 02:32 PM Subject: Re: Is Axis(C++)
Please respond to "Apache stable and mature
AXIS C User List"
Hi!
On Thursday 30 September 2004 14:20, hsong@invatron.com wrote:
> Does anybody have serious web service application development experience
> with Axis(C++)? I want to find out if Axis(C++) is stable and mature,
> compared with Axis(Java), enough for hosting a real enterprise-level web
> service application?
It is still not suitable for the big serious projects. The code is of beta
quality (at best) and some very important features are still missing :-(
Alexei
Re: Is Axis(C++) stable and mature
Posted by Paul Fremantle <pz...@hursley.ibm.com>.
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" <ad...@idsk.com>
>To: "Apache AXIS C User List" <ax...@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
>>
>>
>>
>
>
>
>
Re: Is Axis(C++) stable and mature
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
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" <ad...@idsk.com>
To: "Apache AXIS C User List" <ax...@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
>
Re: Is Axis(C++) stable and mature
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
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" <ad...@idsk.com>
To: "Apache AXIS C User List" <ax...@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
>
Re: Is Axis(C++) stable and mature
Posted by Alexei Dets <ad...@idsk.com>.
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