Interesting feedback . . .

I don’t disable comments on my old posts, and every now and then I get a request or a comment as a result of something I posted. When I pulled down my e-mail today I noticed this little gem waiting for me commented against this post.

And, how is it having your own blog, dude? Considering that you wrote this almost a year ago, and that you probably come out here to talk to yourself on a regular basis, and noone does as little as read it, you must feel very stupid. ‘Cause, that’s what you are; and, unfortunatelly, there is another thousand or so dumbasses like you out there that clog the web with their stupid stories. You dumb f*****g stupid sucker!

Some people are so eloquent don’t you think?

WS-Whatever

Over the past few days I’ve been trying to work with a series of web-services which act as a gateway to a legacy host system. The web-services themselves are exposed over the Internet and built using the Apache Axis 1.0 toolkit. Web-services that are built using Axis tend to use a lot of imports in the WSDL contract which can sometimes be fun to work with. If you come across problems interoperating with Axis from .NET these two patches might be useful.

Anyway, as I took a closer at the contract it seems that they were trying to secure the messages with WS-Security so I decided to throw the WSDL into WSEWSDL2.EXE which comes with WSE 2.0 SP3. Unfortunately thats when the pain started - there were a number of faults in the WSDL contract which meant it wouldn’t work without significant hand editing. Since thats how I think the WSDL contracts got into that state I’m a bit loathed to do that, but it did get me thinking about the importance of interoperability when implementing web-services.

The .NET stack does a pretty reasonable job of abstracting away the job of producing a standards compliant WSDL contracts, but its also very aggressive at ensuring the proxy code it generates is based on equally well formed WSDL and it barfs if something looks out of place. In this case the WSDL file was importing all sorts of wierd XSD files.

Unfortunately I can’t really post the files up here but I did want to have a rant. By the end of today I was pulling my hair out with frustration as I was manually working through the files trying to make them compliant but at what point do you say the service vendor has just cocked up and all they have is tag soup?

I propose a new standard, if you want to say you support web-services in your marketing-ware thats fine. But make sure you put a <wswh:whatever /> header in there so us geeks can ensure we don’t waste any time on you. Sheesh!

WS-Whatever

Over the past few days I’ve been trying to work with a series of web-services
which act as a gateway to a legacy host system. The web-services themselves are
exposed over the Internet and built using the Apache Axis 1.0 toolkit.
Web-services that are built using Axis tend to use a lot of imports in the WSDL
contract which can sometimes be fun to work with. If you come across problems
interoperating with Axis from .NET these two patches
might be useful.

Anyway, as I took a closer at the contract it seems that they were trying to
secure the messages with WS-Security so I decided to throw the WSDL into
WSEWSDL2.EXE which comes with WSE 2.0 SP3. Unfortunately thats when the pain
started - there were a number of faults in the WSDL contract which meant it
wouldn’t work without significant hand editing. Since thats how I think the WSDL
contracts got into that state I’m a bit loathed to do that, but it did get me
thinking about the importance of interoperability when implementing
web-services.

The .NET stack does a pretty reasonable job of abstracting away the job of
producing a standards compliant WSDL contracts, but its also very aggressive at
ensuring the proxy code it generates is based on equally well formed WSDL and it
barfs if something looks out of place. In this case the WSDL file was importing
all sorts of wierd XSD files.

Unfortunately I can’t really post the files up here but I did want to have a
rant. By the end of today I was pulling my hair out with frustration as I was
manually working through the files trying to make them compliant but at what
point do you say the service vendor has just cocked up and all they have is tag
soup?

I propose a new standard, if you want to say you support web-services in your
marketing-ware thats fine. But make sure you put a <wswh:whatever />
header in there so us geeks can ensure we don’t waste any time on you.
Sheesh!