10112RE: [soapbuilders] state of the art on interoperability
- Feb 16, 2005This has been a great discussion, thank you. I'm going to be talking
about some of these issues in a month at the upcoming Emerging
If anyone else from SOAPBuilders will be there, I'd be happy to meet up.
Simon Fell said:
>I think the main reason why folks like Nelson & I see way moreYes, I think you're right. It's not so hard to do integration when you
>problems is because we're building services that are aimed to be used
>by lots of different people with lots of different tools, whilst the
>vast majority of web services deployments today are still back office
>style point to point integrations.
control both the client and the server. But with something like the
Google Web APIs or the Google AdWords API we're publishing a service
to the world and saying "here's the WSDL file, go to it". The result
is our support team has to learn about every problem in every toolkit.
And the debugging is tough, because usually the bug reports come from
users who have never heard of an XML schema and have no idea why all
they get back is "internal fault" or the like.
It's a significant practical problem, and I think it's why you see API
products like Salesforce or eBay distributing client side toolkits
along with the WSDL files.
>With the endpoint we'll test against anyone who wants to test with us.Could you remind me of where to find the endpoint? The Python ZSI guys
are just about to do a new release, maybe they could take a swing at it.
There's a cultural problem here, too. Are any of the current Python,
Perl, or PHP SOAP toolkit developers even on this mailing list? My
impression is SOAPbuilders is mostly done and current interop work has
moved to WS-I, but I don't see a lot of open source hackery happening
in the WS-I world.
>One of the things that I have run into (in the past) is that when theThat's what I do for myself, but it's a lot to ask of users to
>SOAP stack I was using didn't support a newer feature I almost always
>found a way to get what I needed by avoiding the "canned" tooling and
>did a little bit of hand-crafting until the tooling caught up. Would
>this approach work for you?
customize their SOAP toolkits. If you have to go that far, it's
probably easier just to skip the SOAP toolkit entirely and fill in an
XML template. At least with document/literal the XML templates are
simple to understand.
- << Previous post in topic Next post in topic >>