- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
A client of mine made heavy use of WSDL. Many services were called
timerCanceland would acceptargument0,argument1,argument2...Admin
I've lost cost of the number of high-powered super-whizzy jargon-heavy shiny-suited-salespeople System Suppliers who agree to support web services at the sales meetings, and then when Development get involved it turns out that 'support' means ' it's one of the acronyms we put in our SEO '.
I've lost count, but our manglement get sucked in by this every single time ...
Admin
And no, Dev never get invited to the pre-purchase sales meetings. We're too negative and ask too many questions apparently ...
Admin
I once went to a sales meeting in which one of the devs stood up and flat out denied that our product could do what was being asked by the customer. He was technically correct, but we'd made provision to add the functionality. Anyway, he went on to suggest that the customer was stupid to even ask for the missing functionality. We lost the deal.
Admin
The difference between be right and get right
Admin
Incompetent people/teams/organizations (take your pick) should not be used as an excuse to malign any specific technology - certain people can screw up anything. SOAP and WSDL were (and to a degree still are) great ways to accomplish certain goals. [NOTE: My company was producing EDIF libraries as far back as 1989]
Admin
When the article is about fu*ed up XML, you see a literal "<abbr title="Electronic Data Interchange>EDI alone has a dozen subspecifications" and you start to wonder if it is a mistake or trolling.
Admin
"I can see that you are sending requests, but your requests are empty." [...] "I… ah, I cannot find the logs."
So . . . WTF made him say the first part? He was lying? If he wasn't looking at logs, what /was/ he looking at? Certainly not the logs for another service, because Patrick's packets would not have shown up there.
Admin
Incompetence is very hard to debug.
Admin
I had a recent project where a SOAP request was inserted into an apparently unrelated XML envelope for transport. Yes, the preferred method of encoding the inner payload was replacing < and & and > with their escaped versions.
Admin
Yes, these people are often bulls***ting, hoping that the other side is incompetent too and, after some bumbling, will take a hint and just start pretending that everything is working on their end too, and all problems are caused by undetectable aliens. Not a great way to produce something working, passable way to leech some money from equally incompetent management.
Admin
WSDL has one purpose: to describe the programmatic interface to your development tools so things like proxies can be automatically built and things like intellisense are accurate. WSDL was never meant to replace documentation, as it is not an appropriate way to describe the semantics of the API.
People who think XML, SOAP, WSDL and related have failed misunderstood the scope of these technologies.
XML solves a real problem of being an information transport format that can transport any information. XML doesn't specifically address binary data, and is very inefficient if used for such, but is wonderful at dealing with the low level stuff that people in the 90's spent a lot of time on. Just agreeing on separators and how to encode special characters used to be a big deal and is completely a thing of the past now (not just due to XML, but due to the fact that anything after XML had to meet the bar that was already set).
SOAP is a particular flavor of request/response dialog.
WSDL solves the problem of writing boilerplate code to consume SOAP services. Nothing more.
Admin
Re: XML and binary data, we make a type of product that gets hooked up to external control systems (made by third parties), and those control systems require "personality" files that describe how they should present our product's capabilities to the user. Different control systems have different file formats, but sometimes they're XML, and some of them support thumbnail images. One manufacturer's solution to integrating thumbnail support is to just chuck base64 encoded PNG files straight into the XML, which isn't a big deal when most products need only ~12 thumbnails at most. In its standard configuration our product needs 450 and it can be expanded to many many more, so we end up maintaining these files that are really just a thin veneer of XML over megabytes of base64 binary data.
It's one of those things that I want to roll my eyes at, but given the other requirements around the system it's honestly a perfectly fine solution. It's certainly better than another system's solution of having the user FTP thumbnail files with a specific file name scheme into a specific location in the file system of the base Linux machine the control software runs on, so the thumbnails end up completely divorced from the personality file and even the project file the control system is currently running.
Admin
I don't see s problem with this. Saying hello to the world is a sign of peaceful intent and should be welcome. It would be much worse if they deployed a "f*** you world" web service.
Admin
I got a wsdl to communicate with a sap(?) server managed by "corporate" IT of one of our big clients. The wsdl is ok, but they have us a .local url to connect to. We're trying to explain that we're an external company, thus cannot access their intranet. They need to setup a reverse proxy like was agreed when the project kicked off more than a year ago. That seems to much to ask of "corporate" IT... this has been dragging on for over 5 months now.
Admin
I had this with a colleague in the USA. I was getting to work an hour early to overlap with him. Went through all the same steps and debug etc. Turns out he had an exe but they had lost the source code, so all the changes they were asking us to do was to try to "rediscover" the correct format their end was expecting...
Admin
I'm sure you not getting invited to meetings had NOTHING to do with talking to yourself either...
Admin
Steve One, you go that way. Steve Two, come with me.
Admin
Yeah, I agree with both of you here. I actually quite like XML for transporting slightly unpredictable datasets between vaguely incompatible systems, works really well if done right. But it's a rare project where the PM/"architects"/"egg-spurts" really understand this stuff. They usually have a strong opinion, but based on their misunderstanding. Most frequently they seem to have completely missed what the "X" stands for and treat the schema as absolutely brittle, jamming inappropriate things into the wrong element, or adding weird attributes to carry extra data instead of adding new elements.
OK that often happens because they have had, on a previous project, some obstinate arse of a programmer on a legacy system with some homebrewed XML parser that didn't work properly and he absolutely refuses to fix/change. They've found it's easier to get decent coders who know what they're doing to do it the wrong way "just to get things moving" that get Old Bob to do it properly. And then because the project sort of limped into life after a period of pain they learn the wrong lesson. My favourite was an element named <extradata> containing pipe-delimited integers which were actually bitmasked representations of boolean flags, I think the excuse for that was "file sizes".
Nearly all the projects I've been involved with crashed along in a similar fashion to Remy's tale there, the most frustrating one though was where the receiving system was not overseas, it was in the same server room and it's head/admin/programmer/guru sat two desks over from me and not only could he not get his parser to accept compliant and spec perfect XML, he couldn't even give me a decent description of how I should frig the xml so he could read it. Perhaps if he spent more time fixing his crap and less time whinging to everyone in range that I was holding the project up by giving him corrupt files we might have got over the finish line less than 6 months late. At least the project manager on that one wasn't fooled by him.
Admin
This reminds me of another "how does this even happen" conversation I had with a vendor (not for a web service though): they were selling (and configuring for us, I guess) some workflow software. I had a couple of very similar conversations and I might be conflating them, but at some point they made some change, and the button for creating a record was removed. The following dramatisation is kept short and terse for people with shorter attention spans like myself:
Me: "The record creation button is gone. I'm blocked without that button. Please put it back." Vendor: "Use the import button. Here are some instructions on how to find the button." Me: "The record import button is gone. I'm blocked without any button to create records. I've attached a screenshot showing where I expected the button to be and where it isn't." Vendor: "Use the import button. Here are the same instructions as before but worded differently." Me to boss: "I'm out of ideas."
The next morning via a call:
Vendor: "Turns out we didn't provide permissions." Me to myself: "So they didn't have permissions to see a screenshot?"
Once would have been funny, but they also dragged their feet during the entire process, wrote essays for steps which could have been bulleted and reduced down to fewer sentences and didn't get back to us in a timely fashion. Once they put a change into part of our system without telling me (I specifically told them to tell me because I would need to commit it). They weren't entirely the WTF, but I struggled to understand how they got anything done. In the end we scrapped it and went with another vendor.
Admin
After the third failure to produce the correct WSDL, why didn't they just create it themselves and send it along to the other vendor? Perhaps they shouldn't have to, but that would have greatly enhanced the chances of success on the project.
Admin
Sending what amounts to a spec of the other folk's interface does nothing to ensure that those other folks' actual code will implement the interface you wrote for them. When it's their product in the first place.
Admin
Odd that no-one here has mentioned "JSON". Our APIs are all done using JSON with human-readable documentation in various formats.
JSON is better than XML at matching the array&struct format of programming languages. XML is best at being a substrate for HTML, nothing else IMO.
WSDL is more likely to be the bug, because e.g. it doesn't permit a field to be sent that the receiver is expecting or is out-of-date vis-a-vis sender or receiver, than a help.
Admin
"I'm sure you not getting invited to meetings had NOTHING to do with talking to yourself either..." I talk to myself. It's the only way I can get intelligent conversation.
Admin
Sounds like the one time in the early 2000s when we got a requirement for "XML export of content items" in the requirements sheet on a call for bids for a web content management system, and managed to get in by just adding
<?xml version=... ?> <data> <![CDATA[...base64_encoded_serialization_of_internal_data...]]> </data>wrapper to our "save content item to file" implementation ...
We won the bid, and nobody actually ever complained about that "implementation", so it turned out to be right about that just being a "checkbox feature requirement"
Admin
I've been to exactly one pre-purchase meeting in which one of the vendors sent a developer along. We had actually specifically asked for that, so I thought it was nice that they did.
There were three vendors, with one application each.
One of the three was a very shiny product with a lot of documentation which pretty clearly showed that it would not do what we wanted, but it would handle nigh any other situation we might conceivably have within the problem space.
The next product had a sales person who seemed really slick. Anything we asked, he assured us his application could do. He didn't have anything in his slide deck to show it, because it was an unusual request. But it could absolutely do it, and it was trivial.
The last product seemed pretty shoddy, by comparison. It had documented flaws, and one of those seemed very specific to our use case. But we talked with the developer, and we got an idea of how they got to the point where they were, and we at least had the impression that the developer understood our situation, why their product's limitation was an issue, and had some ideas of how to get their application to do what we needed it to do.
I asserted at the meeting with all three companies that I wanted to select the third company (I did not have final authority), and I explained it was mostly because they'd sent the dev we requested. About a week later, we chose the third company.
Eventually, it worked out that it was clearly the right choice, because the second company was sued by multiple customers for false advertising and went out of business, the first company became industry known for being overpriced and under-peforming, and the third product eventually worked and actually cost less than the cheaper of the other two. It did end up costing more than the agreed price, however.