How to run an unproductive web partnership

A customer of mine is setting up a partnership with a web services provider to exchange data over the internet using XML/SOAP, and I got roped in to do the communications part. I've never done this before, but I figured that with all the great toolkits out there I could wing it by plugging stuff together. I'm good enough with perl and problem solving that I figured I could do it.

I ultimately did get it working, but only after much more effort than I should have. These are some tips on how to make it hard for your partners if you're a WSP.

1) Use non-standard extensions

This WSP is using MIME attachments with SOAP messages, and I understand this to be not really common. None of the tools I've used know how to work with them, so it means rolling your own. This is a serious increase in complexity because it means you have to dig into the toolkits to really understand what's going on inside. In their case I'm not sure there was any around using attachments, but this was a complicating factor.

In particular, XML Spy won't read the WSDL because of this, which completely undermined my attempts to use the SOAP debugger to learn this. So as fallback I had to do it the hard way.

2) Don't comment on known-to-work configurations

The WSP must be working with multiple partners, and it's hard to believe they don't get feedback on what works and what doesn't. I'd love to know "Avoid XXX" or "YYY works if you know what you're doing". Even anecdotal reports would be better than starting in the middle of an empty field. The only thing they have said is "We don't recommend any particular tools".

3) Provide broken sample code

The WSP did provide a "soap_wrapper" module in perl that was meant to sit on top of SOAP::Lite. But it was broken in a way that it never could have worked for this particular application (it was hardcoded to use HTTP and wouldn't use HTTPS correctly). There were other problems that caused us to burn a lot of time tracking them down.

In fairness, this code was much better than trying to start from scratch - I'd have been completely lost - but the changes required were really pretty straightforward to somebody who knew the package and would have saved us a ton of time. This suggests they're either not using soap_wrapper themselves or are not distributing updated versions.

4) Make documents hard to get

When we ask for stuff via email (say, XSDs), they usually arrive quickly, but it took more than a week to get the WSDL. It would make so much more sense to have a password-protected "developer partner" page where they could park stuff: documentation, XSDs, WSDL, etc. Then an email saying "Heads up- we changed something, go [HERE] to get them". I can't imagine a partner not wanting the WSDL right away.

5) Change things without telling your partners

After we finally got past the several soap_wrapper options, the "send up a document" API call was failing with an "Invalid API" fault code. This fault code wasn't documented anywhere, and I was sure that it was my own doing. Six hours later I finally sent off an email with full traces asking if they can see what's up, and they responded immediately with "we changed things - use this other API call instead".

Doh!

What's more annoying is that their "fault" message has room for a description string, and it would have been so much more helpful to return "Obsolete method - try YYYY instead" in addition to the "Invalid API" fault code.. I find it hard to believe that I'm the only one who burned time on this, and I'm thankful I didn't start on this on Saturday morning.

 

To be fair, the WSP staff has been exceptionally friendly and eager to help, and I've really enjoyed working with them. In particular, the manager of the group has been great. My guess is that they're under deadlines like everybody else is, and since this is a new service introduction, it's likely that they're simply struggling to keep all the balls in the air.

It's also my guess that their other partners are using consultants with much more experience in XML/SOAP than I have (which wouldn't be that hard), so some of the issues that have stymied me would be mere speed bumps to them. It's not really fair to beat up a vendor for not catering to the least common denominator.

But dealing with your partners should be one of overflowing with information even if these partners are all under nondisclosure. That each partner has to go through the same difficulties makes for a lot of reinvented wheels.

Thankfully, I believe the hard part is behind me famous last words and perhaps I'll get enough experience to do more consulting on these lines.

It's been quite an adventure.

Posted by Steve at August 21, 2002 01:08 PM