anguish
Pat Mueller: I suppose I must not have gotten around to telling Dan my horror stories of using WSDL in the early, early days of Jazz. The low point was when it once took me two working days to get the code working again, after we made some slight changes to the WSDL.
I'll see your WSDL ruined my week and raise you a WSDL caused me extreme pain that could only be soothed by setting my skin on fire and never reading a WSDL document again. I understand the pain associated with WSDL-oriented tools and code generation, but my experience creating those tools was just as difficult. During the first six months of working on the project would become Muse 2.0, the other IBMers that I was working with started asking for client code generation features; I was working well over sixty hours a week at this point, and as important as code generation is for WS-* programmers, I had other things to worry about, like implementing all 9,087 pages of WS-RF. I finally managed to throw something together one weekend, and while it wasn't pretty, it got the job done (for a while).
Eventually, Muse grew and tooling was added, and we needed more code generation support than my weekend side project could provide. Andrew Eberbach started working on a Muse-oriented version of WSDL2Java[1] that actually had a design behind it and, as a result, was much more flexible for both Muse developers and Muse users. During the creation of WSDL2Java, I found myself spending a lot of time trying to transfer my knowledge on the nuances (nuisances?) of WSDL 1.1 and their affect on Java-based service implementations. When I first started at IBM, I had only a cursory knowledge of WSDL, but after two years, I knew what I was doing and had the scars to show for it; unlike many skills (which seem easy once you have them), reading and writing WSDL documents was something that I never got over, and that made it all the more difficult to encourage new students. By the time Muse 2.0 was released, I could read WSDL documents that were thousands (thousands) of lines long and find obscure syntactical or semantic problems in a minute or two... but it never seemed easy.
Never.
The worst part was, even as Andrew picked up my unwritten, unofficial WSDL knowledge and took ownership of our command line tools, it didn't free me from the tyranny of port types, bindings, and <xsd:any/>. As author of Muse's WS-resource deployment and request-processing engines, I had to read WSDL documents at runtime to determine how SOAP requests and WS-Addressing data should be mapped to WS-resource instances and Java method calls[2]. Keeping the WSDL assumptions consistent between tools and engines was tough when I was the only author, so you can imagine what it was like when it was split between two people, one of whom had not yet come to terms with the unstoppable, day-ruining force that was WSDL 1.1.
I really thought that I had a point when I started this rant, but now that I'm nearing the end of it, I can see that I don't. Pat's comment just triggered a flashback and it was either vent through my blog or sit in the corner with spiders crawling over my skin. Whew. Crisis averted.
[1] I believe the first instance of a tool named WSDL2Java was released as part of Apache Axis, but every web services framework I've ever seen has its own implementation of this concept. Muse was no different.
[2] This requirement was put in place in order to avoid another JAX-RPC mapping file disaster.
Labels: muse, narcissism, programming
0 Comments:
Post a Comment
<< Home