This document was generated from CDN thread
Created by: Aaron Graham on 21-04-2010 10:40:07 AM
Hi All,
I suspect that I am not the first to want to do this, but I hope to pass the WSDL and XSD files as provided on the CUCM 7.1, through the gSOAP tool-set to automatically produce client-side C/C++ interface code.
I have download (from the CCM itself) the AXLAPI.WSDL file and its associated XSD files that should allow me to automatically generate the client side SOAP interface code.
When I put the AXLAPI.WSDL through gSOAP's wsdl2h tool, I get issues that relate to targetNamespace differences. See below:
C:\Aarons\CCM_WSDL>wsdl2h -o cucm.h -IC:\Aarons\gsoap-2.7\gsoap AXLAPI.wsdl
** The gSOAP WSDL/Schema processor for C and C++, wsdl2h release 1.2.16
** Copyright (C) 2000-2010 Robert van Engelen, Genivia Inc.
** All Rights Reserved. This product is provided "as is", without any warranty.
** The wsdl2h tool is released under one of the following two licenses:
** GPL or the commercial license by Genivia Inc. Use option -l for more info.
Saving cucm.h
Reading type definitions from type map file 'C:\Aarons\gsoap-2.7\gsoap/typemap.dat'
Reading file 'AXLAPI.wsdl'...
Reading file 'axlsoap.xsd'...
Reading schema file 'axlmessage.xsd'... done reading 'axlmessage.xsd'
done reading 'axlsoap.xsd'
Error: WSDL definitions/import axlsoap.xsd namespace axlapi does not match imported targetNamespace
http://www.cisco.com/AXL/API/7.1
Reading schema file 'axl.xsd'...
Reading schema file 'AXLEnums.xsd'... done reading 'AXLEnums.xsd'
done reading 'axl.xsd'
done reading 'AXLAPI.wsdl'
Warning: no part 'parameters' element '"axlapi":addPhone' in WSDL definitions '' namespace
Warning: no part 'parameters' element '"axlapi":addPhoneResponse' in WSDL definitions '' namespace
Warning: no part 'parameters' element '"axlapi":removePhone' in WSDL definitions '' namespace
Warning: no part 'parameters' element '"axlapi":removePhoneResponse' in WSDL definitions '' namespace
Warning: no part 'parameters' element '"axlapi":updatePhone' in WSDL definitions '' namespace
...
...
I am sure pretty sure that the warnings relate to the preceding namespace Error above.
When I load the WSDL file into XML Spy it also confirms that namespaces are an issue.
The XSD files and structure seem to be ok. When I load the top XSD (axlsoap.xsd) into XML Spy, it reports that it is valid.
The CCM WSDL is also provided as two special cases, one for WSDL-AXIS (for java client development I believe) and WSDL-NET (for .NET clients). I have read from the "Cisco Unified Communications Manager XML Developers Guide" under a section entitled "Returned Namespace for AXL and .NET applications":
"By default, the AXLAPI.wsdl carries the namespace http://www.cisco.com/AXL/API/7.0 The generated client stubs also have this namespace. In some situations, you must change the namespace in AXLAPI.wsdl before creating the client stubs."
I am wondering if I have to make similar namespace changes to get the WSDL file to work with gSOAP?
Any comments or help regarding this would be greatly appreciated.
Thanks in advance.
Aaron
Subject: RE: Using WSDL to generate C++ using gSOAP
Replied by: David Staudt on 21-04-2010 04:58:20 PM
You might try the variations in the Axis and .NET specific folders. These are modified and merged to be less complicated and remove problems some compilers have. I've found the Axis version to be the most friendly across various AXL compilers.
Modifying the wsdl/xsd to work with specific compilers is commonly needed.
Subject: RE: Using WSDL to generate C++ using gSOAP
Replied by: Gilad Ben-Ami on 26-04-2010 11:13:57 AM
Hi,
Have you managed to overcome this issue?
I'm also interesting in working with gSOAP to access AXL service on CUCM.
Thanks,
Gilad.
Subject: RE: Using WSDL to generate C++ using gSOAP
Replied by: Aaron Graham on 27-04-2010 02:50:19 PM
Hi, No I am still trying to get a Cisco Developer Support contract organised so I can direct my queries to people who might know more about AXL, WSDL and the CUCM.
So frustrating....
Aaron
Subject: RE: Using WSDL to generate C++ using gSOAP
Replied by: David Staudt on 27-04-2010 10:40:36 PM
I'm on the Cisco DS team
Being that every WSDL compiler has different capabilities and foibles, and that the AXL WSDL is complex (and sometimes a bit odd) Cisco does not support every possible WSDL compiler. Up until quite recently, the demarcation point for Developer Support was strictly at the XML level - i.e. validating XML requests/responses. In the latest releases, the engineering teams now are doing basic sanity compilation with Axis and .NET WSDL compilers (only) and have engineered some changes in the WSDL designed to help those compilers work well - supposedly in UCM 8.0 the WSDLs compile out of the box. Support for actually programming with the Java/C# stubs is a bit beyond DS scope. Support for other compilers is not contemplated currently.
I attempted today to do a header generation using gSoap 1.2.9 against the Axis version of the AXL 7.0 WSDL. While I got no errors, it used 100% CPU for about 3 hours with no results - so I killed it. If you definitely need to progress with gsoap, it may be possible to look at the problem from that end - i.e. contact the gsoap folks and see why/where their compiler is gumming up on AXL. It's possible some of the many gsoap command line options could solve the problem, or that a debug version may provide some insights. It's possible that the AXL WSDL could use some small tweaks to help it work with gsoap (while not breaking Axis/.NET compilation.) If so let us know.
If you are only using a small handful of AXL requests, in many cases (even with Axis/.NET) it is sometimes simpler just to use an XML/DOM parser and handle the request/response as an XML exchange - or even just use string parsing. This was the original main usage of AXL, and many developers have used it successfully over the years. We have recognized that WSDL/compile is now the main usage case, hence the improved support for the two main WSDL compilers.
Created by: Aaron Graham on 21-04-2010 10:40:07 AM
Hi All,
I suspect that I am not the first to want to do this, but I hope to pass the WSDL and XSD files as provided on the CUCM 7.1, through the gSOAP tool-set to automatically produce client-side C/C++ interface code.
I have download (from the CCM itself) the AXLAPI.WSDL file and its associated XSD files that should allow me to automatically generate the client side SOAP interface code.
When I put the AXLAPI.WSDL through gSOAP's wsdl2h tool, I get issues that relate to targetNamespace differences. See below:
C:\Aarons\CCM_WSDL>wsdl2h -o cucm.h -IC:\Aarons\gsoap-2.7\gsoap AXLAPI.wsdl
** The gSOAP WSDL/Schema processor for C and C++, wsdl2h release 1.2.16
** Copyright (C) 2000-2010 Robert van Engelen, Genivia Inc.
** All Rights Reserved. This product is provided "as is", without any warranty.
** The wsdl2h tool is released under one of the following two licenses:
** GPL or the commercial license by Genivia Inc. Use option -l for more info.
Saving cucm.h
Reading type definitions from type map file 'C:\Aarons\gsoap-2.7\gsoap/typemap.dat'
Reading file 'AXLAPI.wsdl'...
Reading file 'axlsoap.xsd'...
Reading schema file 'axlmessage.xsd'... done reading 'axlmessage.xsd'
done reading 'axlsoap.xsd'
Error: WSDL definitions/import axlsoap.xsd namespace axlapi does not match imported targetNamespace
http://www.cisco.com/AXL/API/7.1
Reading schema file 'axl.xsd'...
Reading schema file 'AXLEnums.xsd'... done reading 'AXLEnums.xsd'
done reading 'axl.xsd'
done reading 'AXLAPI.wsdl'
Warning: no part 'parameters' element '"axlapi":addPhone' in WSDL definitions '' namespace
Warning: no part 'parameters' element '"axlapi":addPhoneResponse' in WSDL definitions '' namespace
Warning: no part 'parameters' element '"axlapi":removePhone' in WSDL definitions '' namespace
Warning: no part 'parameters' element '"axlapi":removePhoneResponse' in WSDL definitions '' namespace
Warning: no part 'parameters' element '"axlapi":updatePhone' in WSDL definitions '' namespace
...
...
I am sure pretty sure that the warnings relate to the preceding namespace Error above.
When I load the WSDL file into XML Spy it also confirms that namespaces are an issue.
The XSD files and structure seem to be ok. When I load the top XSD (axlsoap.xsd) into XML Spy, it reports that it is valid.
The CCM WSDL is also provided as two special cases, one for WSDL-AXIS (for java client development I believe) and WSDL-NET (for .NET clients). I have read from the "Cisco Unified Communications Manager XML Developers Guide" under a section entitled "Returned Namespace for AXL and .NET applications":
"By default, the AXLAPI.wsdl carries the namespace http://www.cisco.com/AXL/API/7.0 The generated client stubs also have this namespace. In some situations, you must change the namespace in AXLAPI.wsdl before creating the client stubs."
I am wondering if I have to make similar namespace changes to get the WSDL file to work with gSOAP?
Any comments or help regarding this would be greatly appreciated.
Thanks in advance.
Aaron
Subject: RE: Using WSDL to generate C++ using gSOAP
Replied by: David Staudt on 21-04-2010 04:58:20 PM
You might try the variations in the Axis and .NET specific folders. These are modified and merged to be less complicated and remove problems some compilers have. I've found the Axis version to be the most friendly across various AXL compilers.
Modifying the wsdl/xsd to work with specific compilers is commonly needed.
Subject: RE: Using WSDL to generate C++ using gSOAP
Replied by: Gilad Ben-Ami on 26-04-2010 11:13:57 AM
Hi,
Have you managed to overcome this issue?
I'm also interesting in working with gSOAP to access AXL service on CUCM.
Thanks,
Gilad.
Subject: RE: Using WSDL to generate C++ using gSOAP
Replied by: Aaron Graham on 27-04-2010 02:50:19 PM
Hi, No I am still trying to get a Cisco Developer Support contract organised so I can direct my queries to people who might know more about AXL, WSDL and the CUCM.
So frustrating....
Aaron
Subject: RE: Using WSDL to generate C++ using gSOAP
Replied by: David Staudt on 27-04-2010 10:40:36 PM
I'm on the Cisco DS team
Being that every WSDL compiler has different capabilities and foibles, and that the AXL WSDL is complex (and sometimes a bit odd) Cisco does not support every possible WSDL compiler. Up until quite recently, the demarcation point for Developer Support was strictly at the XML level - i.e. validating XML requests/responses. In the latest releases, the engineering teams now are doing basic sanity compilation with Axis and .NET WSDL compilers (only) and have engineered some changes in the WSDL designed to help those compilers work well - supposedly in UCM 8.0 the WSDLs compile out of the box. Support for actually programming with the Java/C# stubs is a bit beyond DS scope. Support for other compilers is not contemplated currently.
I attempted today to do a header generation using gSoap 1.2.9 against the Axis version of the AXL 7.0 WSDL. While I got no errors, it used 100% CPU for about 3 hours with no results - so I killed it. If you definitely need to progress with gsoap, it may be possible to look at the problem from that end - i.e. contact the gsoap folks and see why/where their compiler is gumming up on AXL. It's possible some of the many gsoap command line options could solve the problem, or that a debug version may provide some insights. It's possible that the AXL WSDL could use some small tweaks to help it work with gsoap (while not breaking Axis/.NET compilation.) If so let us know.
If you are only using a small handful of AXL requests, in many cases (even with Axis/.NET) it is sometimes simpler just to use an XML/DOM parser and handle the request/response as an XML exchange - or even just use string parsing. This was the original main usage of AXL, and many developers have used it successfully over the years. We have recognized that WSDL/compile is now the main usage case, hence the improved support for the two main WSDL compilers.