Easy Peesy

Making it stick.: The "Ease" Argument Again?

I've got Patrick's back on this one, I have a hard time believing that anything that starts with WSDL is going to make my life easier.

I like Dan's project, I do. I think XFire is the way to go if you have a hard and fast requirement to expose a Java-based service via SOAP. But make sure you actually need to go there before you do. If your biggest customer says "we use SOAP and only SOAP" for integration with trading partners, hello XFire.

Thus lies the path to Kakotopia! In my experience, you won't be pointing any tools at each other that actually grok that WSDL and can talk to each other without serious intervention on your part. My last experience trying to do this very thing was a Java/.NET integration for a project was about two years ago, the experience went something like this:

1) Expose XFire service by configuring Spring adapter booya
2) Check WSDL - looks OK, not that I'd know without studying the spec
3) Use VisualStudio .NET Stub generator wizard to create a C# class for invoking the service.
4) Try and run the class from step 3
5) Witness failure, something about unsupported binding
6) Read this.
7) Change API to XML-RPC.

I have about eight of these stories, some of them end with me snooping HTTP Headers because of obscure server errors. Some, like a recent attempt to create a Flex service to consume Confluence's WSDL end with obtuse client-side schema errors. That's about all the CPU cycles I give to these types of things, after that I fall back to things I can control and see. Maybe some day it will work, but I haven't seen it materialize yet.

Given recent episodes with REST, I'm not sure it's a clear winner from the browser either, because I again find myself looking at HTTP Headers to try and figure out what is broken. I don't want to spend my time doing that. Seriously, I'm done breaking out Wireshark to troubleshoot protocols that work until people try and get cute with them.