Gordon Ross | I had a quick look at your page. In it, you say that you're going to describe the parse-as-string and full-WSDL options, and ignoring the XML approach.
A couple of thoughts.
I've tried many times to get the "proper" WSDL/SOAP solution working with Java. However, I could never get the WSDLs to work with Apache AXIS (either V1 or V2) From what I've glanced on the forums, people seem to have more luck with other languages and the WSDL approach.
I have to confess, that I'm not a great fan of the "Parse XML as string" approach - but do what you're happy with.
I use the XML approach - but not for the every SOAP call. I've written a little library which is hard coded to parse the executeSQL (& updateSQL) SOAP calls. My executeSQL parse takes the SQL SELECT result and turns it into a List<HashMap<String, String>> (so each row is a HashMap<String, String>, and the result set is a List of these HashMaps)
I find there are several advantages to this.
Firstly, you can be more specific about the data that is returned. By restricting the data that is returned, your app becomes much more efficient in terms of database access.
Secondly, you can implement API calls that Cisco don't provide via the official SOAP interface. After having a (very) quick look at the SOAP APIs, it seems they are modeled on the CCMADMIN user interface. All well and good. But really, you probably want to do things that aren't in the CCMADMIN interface. By using the native database tables, you can get much more power and performance out of the sysem.
GTG |