>>My advice: If you have a well running example in .Net, Java or Python create a wrapper and access that via COM. If installation woes/fears do not allow that, do it manually either via XmlHTTP for very basic stuff or one of Rick's classes, as he conquered some of the pitfalls.
>
>I second that. Manually dealing with XML parsing and generation may work now, but once you update the service it'll be incredibly difficult to reconcile changes or update. It's also very easy to mess up parsing and not know it - getting back invalid types or empty/missing values. Been there done that and regretted it each time even though it seemed easier at the time :-) The problem is that that code gets incredibly messy and is a morass to maintain and debug, especially after you've stepped away from it for a little while.
>

Embolded is the reason on seeing the XmlHTTP path followed I argued to rewrite in a version as DRY as possible, separating Post, XML generation, XML parsing and so on into small methods easy to reassemble on changes. My own code for the times I had to follow that path is slightly across the borders on over-engineered with 1-line methods equipped sometimes with logging hooks, version table for config, path, schema and other strings as well as some factory logic to load classes versioned dynamically into logical property names and execute "actions" via template methods with ample hooks in each method to ease injecting, sometimes changing, something working previously ;-))

One of the places YAGNI does not come into play and one of the times I really missed the monkey patching and or multiple inheritance
available in Python or JS where you can assign functions from one object to another to build the "correct" handler for each particular revision - single inheritance not up to it in this case. ;-)