- 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
There's a bit of wtf-fanboy overreacting going on here. As far as a SOA goes this system could be very useful. If you have a lot of applications in an enterprise environment (wooo) requiring this service, the xml based approach to passing the data is much more efficient than sending strings (think of how many businesses have legacy C++ applications working with newer java or .NET apps).
Maybe that's not the ideal design of the DTD -- maybe that's the wtf here, but its not a great one as far as dailywtfs go.
Admin
I just wanted to mention that aside from the obvious WTF of using an XML string as a parameter to a local function call, we have a similar web service within my organization, and it is invaluable.
The web service is used by many different applications. We're an ASP & .NET shop, so the web service and associated API emulates the interface of the SmtpMail object in .NET and whatever object we use in ASP (I don't touch the sutff) to send e-mail.
In our test environment, it strips the tos, ccs, and bccs from the headers, appends them to the message body, and posts the e-mail to a public folder on our Exchange server. That way we don't ever accidentally send test e-mails to real people.
In our production environment, every e-mail sent is checked against our opt-out database, so that a person needs only opt out of a specific type of e-mail once in a single application, and that way we can be assured that they will never recieve that type of e-mail from any of our applications.