This rules. This is the bane of my existence. At Proto, we are always trying to build (or help people build) cool apps that consume WSDLs and generate handy Proto interfaces to web services. When it works, it's awesome. It's very easy to use. In Proto, you paste in your WSDL URI and Proto uses .NET's WS stack to generate some proxy classes you never have to see, which it handily exposes Proto-style (input and output menus) and it more-or-less magically deals with type conversions, data structures, etc. When we first added this feature to test builds of Proto, we tried it with the Google Search WSDL, which used XML-RPC IIRC (RIP). It was one of those times where you're like, "let's see if this works". We pasted in a URI, clicked a button, and all of the sudden, we had a Proto module with inputs like "Set Search Query" and outputs like "Get Results" that we could connect anything to: Proto input modules like textboxes, Excel cells, all sorts of stuff. It took a few seconds to set up. Very cool.
However, the WS-* stack is so complicated that (1) .NET is not even close to perfectly interoperable with all endpoints. Not even close. For example, the last time I checked the .NET 1.1 libs could not parse the Amazon S3 WSDL. It's not like the joker implementations aren't interoperable, it's the people who ostensibly know what they are doing. (2) We don't implement/expose every option. In fact, we don't even understand every option. The specs seem to be internally contradictory, overlapping, or vague, so we chose what we considered to be a reasonable subset to implement by inspecting a wide array of services, and went with it. This means every so often we hit a service we can't use because it relies on a feature we didn't implement. For the record, as far as I can tell, everyone does this. I'm not sure if a complete implementation of those specs is even logically possible. The last time I checked, .NET didn't implement certain features of WSDL or SOAP, but I can't remember exactly what. In fact, the practice is so prevalent, there is an industry group dedicated to picking which parts are safe to use. Even with this magical tooling stack (I have to assume the .NET implementation is one that every vendor would test against), we still end up in situations where it's faster and easier to write a little VBA code in a module to hit a reasonably RESTy 'web service' (in the traditional sense of 'all web endpoints represent web services').
I have two distinct suspicions about this type of engineering. The first is that I'm struck by how much this feels like C++ in the 90s (can't keep the design in your head, no complete implementations, industry WGs working on an 'ok to use' subset, etc.) . I'm not saying C++ isn't powerful and useful and used successfully in all sorts of mission critical applications (and Bjarne Stroustrup lived down the block from my friend when we were in middle school. You gotta support the home team) , but haven't we learned some important lessons about that sort of thing? Things that can save us some agita nowadays? Again, I fully admit my second is a not a provable hypothesis, but it is a strong suspicion: I suspect the document-oriented design of REST-style web services makes a lot more sense as a distributed computing architecture for the bulk of distributed computing applications, not all, but the bulk, as opposed to "hey lets have distributed objects with methods we can call just like normal, and pretend the network doesn't exist! The tools will take care of it! W00t!1!"
Comments