Return-Path: Delivered-To: apmail-ws-axis-c-user-archive@www.apache.org Received: (qmail 57389 invoked from network); 11 Feb 2010 22:58:28 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 11 Feb 2010 22:58:28 -0000 Received: (qmail 84622 invoked by uid 500); 11 Feb 2010 22:58:28 -0000 Delivered-To: apmail-ws-axis-c-user-archive@ws.apache.org Received: (qmail 84567 invoked by uid 500); 11 Feb 2010 22:58:27 -0000 Mailing-List: contact axis-c-user-help@ws.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: List-Id: "Apache AXIS C User List" Reply-To: "Apache AXIS C User List" Delivered-To: mailing list axis-c-user@ws.apache.org Received: (qmail 84558 invoked by uid 99); 11 Feb 2010 22:58:27 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 11 Feb 2010 22:58:27 +0000 X-ASF-Spam-Status: No, hits=-1.8 required=10.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of amra@us.ibm.com designates 32.97.182.142 as permitted sender) Received: from [32.97.182.142] (HELO e2.ny.us.ibm.com) (32.97.182.142) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 11 Feb 2010 22:58:17 +0000 Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by e2.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id o1BMm2rG009774 for ; Thu, 11 Feb 2010 17:48:02 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o1BMvtJo139122 for ; Thu, 11 Feb 2010 17:57:55 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o1BMvtBS030908 for ; Thu, 11 Feb 2010 17:57:55 -0500 Received: from d27ml101.rchland.ibm.com (d27ml101.rchland.ibm.com [9.10.229.40]) by d01av04.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o1BMvtDV030898 for ; Thu, 11 Feb 2010 17:57:55 -0500 In-Reply-To: <9C55040DA84D3D4C936A896505A1F64E010668F2@mail2.oxymelfr.com> References: <27518586.post@talk.nabble.com> <9C55040DA84D3D4C936A896505A1F64E010668F1@mail2.oxymelfr.com> <9C55040DA84D3D4C936A896505A1F64E010668F2@mail2.oxymelfr.com> To: "Apache AXIS C User List" MIME-Version: 1.0 Subject: =?ISO-8859-1?Q?RE=A0=3A_Need_suggestions_on_Axis=2Fc_client_stub?= X-KeepSent: 84F297DB:A29484DC-862576C7:007D3537; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2FP1 SHF149 July 17, 2009 Message-ID: From: Nadir Amra Date: Thu, 11 Feb 2010 16:57:49 -0600 X-MIMETrack: Serialize by Router on d27ml101/27/M/IBM(Release 8.0.2FP2|June 22, 2009) at 02/11/2010 04:57:54 PM, Serialize complete at 02/11/2010 04:57:54 PM Content-Type: multipart/alternative; boundary="=_alternative 007E3002862576C7_=" X-Virus-Checked: Checked by ClamAV on apache.org This is a multipart message in MIME format. --=_alternative 007E3002862576C7_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable 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: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D AxisC++ is a very good, solid, 2nd generation Web Services stack written=20 in C++. It supports being a client to UDDI, and certainly it would be=20 possible to support WS-Sec under it. However standards like RM and=20 WS-Addressing are hard to support.=20 If you look at the iterations of development, the first iteration (e.g.=20 ApacheSOAP) was just about getting the job done simply. The next iteration = added better parsing and more flexible handler models, which successfully=20 supports WSSecurity and simple extensions to SOAP.=20 However, the big change has been WS-Addressing, which has made WS much=20 more asynchronous and message based. Unfortunately a lot of WS stacks=20 including Axis/Java 1.x and Axis/C++ 1.x were built with a very RPC-like=20 model.=20 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=20 again.=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D So basically Axis2/C and Axis2/Java were created to support more of the=20 standards and improve on what was learned in prior implementations. Nadir Amra Olivier Mengu=E9 wrote on 02/11/2010 03:57:55 AM: > [image removed]=20 >=20 > RE : Need suggestions on Axis/c client stub >=20 > Olivier Mengu=E9=20 >=20 > to: >=20 > Apache AXIS C User List, Apache AXIS C User List >=20 > 02/11/2010 04:02 AM >=20 > Cc: >=20 > "Apache AXIS C User List" >=20 > Please respond to "Apache AXIS C User List" >=20 >=20 >=20 > De: Nadir Amra > >Axis-C++ client-side is not broken or buggy. It is perfectly=20 functional > >and in some cases much easier to use than axis2/C. >=20 > So why Axis2/C was created? I'm insterested in the history of the=20 project. > Is it because "C support is not complete." in Axis C++ ? > (according to http://ws.apache.org/axis/cpp/index.html#Known=5Fissues ) >=20 > Olivier.=20 --=_alternative 007E3002862576C7_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
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:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
AxisC++ is a very good, solid, 2nd generation Web Servic= es 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.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


So basically Axis2/C and Axis2/Java were created to support more of the standards and improve on what was learn= ed in prior implementations.

Nadir Amra


Olivier Mengu=E9 <omengue@oxymel.com> wrote on 02/11/2010 03:57:55 AM:

> [image removed]

>
> RE : Need suggestions on Axis/c client stub

>
> Olivier Mengu=E9

>
> 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/inde= x.html#Known=5Fissues )
>
> Olivier.
--=_alternative 007E3002862576C7_=--