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 Olivier Mengué <om...@oxymel.com> on 2010/02/10 11:41:51 UTC
RE : Need suggestions on Axis/c client stub
Hi
I'm a recent Axis2/C user. I don't know about Axis-C/C++.
Ashok P wrote:
>3) As per the documentation, axis-c supports "ADB" binding for client code
>generations and "none" option for raw xml in/out. Is ADB is efficient to
>consume non-axis web services?
I don't know what is "ADB binding".
With Axis2/C I had to do manual XML tree building. The Axis2 codegen tool was not able to
generate the XML tree building for my WSDL.
>5) Does it mandatory to use axis2.xml? I like all these settings through
>code by settings the options - like settings the protocol "http" or https
>(ssl), port , ssl certificate, client timeout and more. Does such provision
>is available in both C/C++ client generated code?
I'm interested by an answer to this question too.
>6) From the other posting on forum, it's not clear that "AXIS2C_HOME"
>deplorer folder is mandatory or not for client side. Can anybody confirm
>this?
It seems to be mandatory to use AXIS2C_HOME as it is the way to find the axis2.xml.
axis2.xml is AFAIK mantadory for client side.
> I agree few Dlls are required for client distribution. I like my
>client application (along with client stub) should have small footprint for
>distribution, so can I build stub statically for depended libraries like
>axiom.dll, axis2_http_sender.dll etc?
It looks like the transport layers (http_sender, http_receiver...) are loaded dynamically by Axis2/C.
And there is no option in the build system to make a build with statically linked transports.
>7) Axis-C++ is not recommended for production use. Does I need to test
>client generated (stub) for stability considering the recommendation? Any
>suggestions on axis-c++ clients to be used on production? Otherwise I need
>go with axis-c only.
The recommandation is to use Axis2/C (which is not axis-c).
I understood it as "Axis-C++ is buggy and is broken by design, we choose to rewrite everything as Axis2/C". Is it really the case? I don't know. That is just the feeling I got by reading the site.
Olivier Mengué
RE : Need suggestions on Axis/c client stub
Posted by Nadir Amra <am...@us.ibm.com>.
Actually, C support is as complete as the C++ support. But only on client
side, and only for doc/literal.
>From an old post when I asked the question long ago:
============
AxisC++ is a very good, solid, 2nd generation Web Services stack written
in C++. It supports being a client to UDDI, and certainly it would be
possible to support WS-Sec under it. However standards like RM and
WS-Addressing are hard to support.
If you look at the iterations of development, the first iteration (e.g.
ApacheSOAP) was just about getting the job done simply. The next iteration
added better parsing and more flexible handler models, which successfully
supports WSSecurity and simple extensions to SOAP.
However, the big change has been WS-Addressing, which has made WS much
more asynchronous and message based. Unfortunately a lot of WS stacks
including Axis/Java 1.x and Axis/C++ 1.x were built with a very RPC-like
model.
Axis2 C is the start of the move of Axis in C/C++ to the Axis2 model. When
we wrote Axis2/Java we started again. In building Axis2/C we also started
again.
===========
So basically Axis2/C and Axis2/Java were created to support more of the
standards and improve on what was learned in prior implementations.
Nadir Amra
Olivier Mengué <om...@oxymel.com> wrote on 02/11/2010 03:57:55 AM:
> [image removed]
>
> RE : Need suggestions on Axis/c client stub
>
> Olivier Mengué
>
> to:
>
> Apache AXIS C User List, Apache AXIS C User List
>
> 02/11/2010 04:02 AM
>
> Cc:
>
> "Apache AXIS C User List"
>
> Please respond to "Apache AXIS C User List"
>
>
>
> De: Nadir Amra
> >Axis-C++ client-side is not broken or buggy. It is perfectly
functional
> >and in some cases much easier to use than axis2/C.
>
> So why Axis2/C was created? I'm insterested in the history of the
project.
> Is it because "C support is not complete." in Axis C++ ?
> (according to http://ws.apache.org/axis/cpp/index.html#Known_issues )
>
> Olivier.
RE : Need suggestions on Axis/c client stub
Posted by Olivier Mengué <om...@oxymel.com>.
De: Nadir Amra
>Axis-C++ client-side is not broken or buggy. It is perfectly functional
>and in some cases much easier to use than axis2/C.
So why Axis2/C was created? I'm insterested in the history of the project.
Is it because "C support is not complete." in Axis C++ ?
(according to http://ws.apache.org/axis/cpp/index.html#Known_issues )
Olivier.
Re: RE : Need suggestions on Axis/c client stub
Posted by Ashok P <as...@gmail.com>.
Thanks to all for suggestions and inputs.
Any suggestions on point-1 - data type mapping? for example if you check
typemap.dat in case of gsoap which gives us a easy way to map data types. I
am planning to take a look on code generation source code. Will it work if I
change for data types?
I will update on point 5 and 6 as I started investigations on it.
/// Ashok
Nadir Amra wrote:
>
> Axis-C++ client-side is not broken or buggy. It is perfectly functional
> and in some cases much easier to use than axis2/C.
>
>
> Nadir Amra
>
>
> Olivier Mengué <om...@oxymel.com> wrote on 02/10/2010 04:41:51 AM:
>
>> [image removed]
>>
>> RE : Need suggestions on Axis/c client stub
>>
>> Olivier Mengué
>>
>> to:
>>
>> Apache AXIS C User List
>>
>> 02/10/2010 04:42 AM
>>
>> Please respond to "Apache AXIS C User List"
>>
>> Hi
>>
>> I'm a recent Axis2/C user. I don't know about Axis-C/C++.
>>
>> Ashok P wrote:
>>
> .
> .
> .
>>
>> >7) Axis-C++ is not recommended for production use. Does I need to test
>> >client generated (stub) for stability considering the recommendation?
> Any
>> >suggestions on axis-c++ clients to be used on production? Otherwise I
> need
>> >go with axis-c only.
>>
>> The recommandation is to use Axis2/C (which is not axis-c).
>> I understood it as "Axis-C++ is buggy and is broken by design, we
>> choose to rewrite everything as Axis2/C". Is it really the case? I
>> don't know. That is just the feeling I got by reading the site.
>>
>> Olivier Mengué
>
>
--
View this message in context: http://old.nabble.com/Need-suggestions-on-Axis-c-client-stub-tp27518586p27542741.html
Sent from the Axis - C++ - User mailing list archive at Nabble.com.
RE : Need suggestions on Axis/c client stub
Posted by Nadir Amra <am...@us.ibm.com>.
Axis-C++ client-side is not broken or buggy. It is perfectly functional
and in some cases much easier to use than axis2/C.
Nadir Amra
Olivier Mengué <om...@oxymel.com> wrote on 02/10/2010 04:41:51 AM:
> [image removed]
>
> RE : Need suggestions on Axis/c client stub
>
> Olivier Mengué
>
> to:
>
> Apache AXIS C User List
>
> 02/10/2010 04:42 AM
>
> Please respond to "Apache AXIS C User List"
>
> Hi
>
> I'm a recent Axis2/C user. I don't know about Axis-C/C++.
>
> Ashok P wrote:
>
.
.
.
>
> >7) Axis-C++ is not recommended for production use. Does I need to test
> >client generated (stub) for stability considering the recommendation?
Any
> >suggestions on axis-c++ clients to be used on production? Otherwise I
need
> >go with axis-c only.
>
> The recommandation is to use Axis2/C (which is not axis-c).
> I understood it as "Axis-C++ is buggy and is broken by design, we
> choose to rewrite everything as Axis2/C". Is it really the case? I
> don't know. That is just the feeling I got by reading the site.
>
> Olivier Mengué