Microsoft Rinses SOAP Out of SQL Server 2008

Julie188 writes "A Microsoft SQL Server 2005 fan toppled over in surprise when he got this error message from SQL Server 2008 (he was running the SQL Server 2008 Upgrade Advisor tool): 'In SQL Server 2008, SQL Server native SOAP has been deprecated and will be removed in a future SQL Server release ... Avoid use of SQL server native SOAP in new development work, and plan to modify applications that currently use it.' No more SOAP-based Web services for your SQL Server database? Native XML was only added in v.2005 and was much ballyhooed at that time."

Comments

Lather, Rinse, Repeat

[Jeremiah Cornelius]

Maybe because SOAP (Simple Object Access Protocol) has proven to be a dead-end, particularly for structured data storage, and especially in the pursuit of "cloud" services.

No one is turning back on XML or serialized application interfaces over HTTP. The storage interfaces will be accessible using some REST oriented API.

Re:Lather, Rinse, Repeat

[abigor]

Exactly. SOAP is a nightmare product of design by committee, which probably explains why it was so enthusiastically adopted by Java (awaiting my "-1, Flamebait", but it's true, and I say this as someone who is writing web services code in Java using SOAP right at this very minute).

The whole framework just feels wrong. REST and/or a much simpler rpc framework like xmp-rpc is the way to go.

Re:Lather, Rinse, Repeat

[BillAtHRST]

"There are about 3-4 different ways you can do each of them, with two of them being official or semi-official."

Isn't that the whole problem with Java in a nutshell? I like the language OK, but all the framework stuff bolted on to it, combined with "deprecated"-this and "deprecated"-that, really cause a geometric explosion in what one needs to understand and/or support in that environment.

Re:Lather, Rinse, Repeat

[jrumney]

And history will repeat, with committees appointed to heap layer upon layer of extra complication upon XML-RPC and REST in the name of standardization. It seems that every distributed RPC protocol is destined to repeat the pattern of CORBA, being replaced by a simpler, easy to use protocol, then becoming more and more complicated as committees add the features required to meet the security and interoperability needs of all its users.

Re:Lather, Rinse, Repeat

[spotvt01]

What's the old saying? "It's a poor craftsman who blames his tools?" ;-)

yeah, that's certainly one way to look at it ... here are a few others: "when all you have is a hammer, everything looks like a nail" and my personal favorite "the right tool for the right job; would you strike a nail with a fly swatter or kill a fly with a hammer?" I think you might have misused the quotation. The real point behind your above quotation is that craftsman should know how to choose, use, and maintain his/her tools. In our industry we often find ourselves falling in on other peoples poor choices, i.e. my brother was asked to maintain some code to search M$ Office files that was written in FORTRAN. I could go on, but we all have experienced this.

Use a web server

[truthsearch]

No more SOAP-based Web services for your SQL Server database?

Not exactly. It means no more SOAP-based Web services directly served from your SQL Server. Now you have to go back to using a web server application like god intended.

Re:SOAP

[Anonymous Coward]

Oh sweet. The paranoia of the FOSS zombies. It was sorely needed in this thread.

Its hilarious how FOSS zealots can get away with saying any rubbish on a technical forum. Seriously.

Probably in the last decade MS didnt have to spend a single dime to make FOSSies shit their pants whenever any MS news came out. Go rant on your blog shitcake. Keep this forum for technical discussion, and not for your dumping your delusions.

SOAP

[coryking]

Why can't one of these new fanged RPC thingies HANDLE FUCKING AUTHENTICATION and AUTHORIZATION in a standard way? And if there *is* a standard way, I dont know about, WHY IS IT NOT OBVIOUS AND EASY!?

Why do I *have* to roll my own fucking way to hold a session using SOAP? Why couldn't they have some concept of a cookie or some easy way to maintain state that was buried deep within the protocol so it was transparent to me?

All these XML based RPC specs suck ass. Some architechure astronauts snorted a bunch of crack and decided to do crazy stuff like let you use SMTP for a transport. It would be much simpler to just pick a damn transport and stick with it so you can exploit the charctaristics of said transport (like cookies for HTTP or ??? for SMTP).

Unless you trust your IDE and dont need to get say, a C# client to talk to a mod_perl backend, you are in a world of hurt. For that matter, if you use any kind of dynamic language (PHP, Ruby, Perl), god help you with anything. You'll be writing a fuckton of XML that you'll have to keep in sync with your codebase. Forget any kind of automated tools.

In short, screw SOAP. Keep it fucking simple!!!

Why would you want SOAP in SQL Server?

[MobyDisk]

I write SOAP web services in C# for a living. Those services use SQL servers. But I would never want to combine the two. What the heck...? Was Microsoft trying to make SQL Server be this uber thing that did web services, parsed XML, and served data? What a horrible idea.

There is quite a bit of deprecation in javax.swing

[Gazzonyx]

This hurts, but I've gotta' say it.

While I generally agree with you, AKAImBatman, I think you've missed the mark on this one. The Serializable interface has been deprecated and will not be forward compatible. Unfortunately, this affects (effects? I always get them mixed up...) just about everything in the javax.swing package.

Granted, swing is somewhat ugly, single threaded (discounting worker threads - you still only have one dispatcher to do painting, anyways... although I want to choke everyone who tries to do everything on the dispatcher and wonders why nothing is responsive), and a generally over engineered toolkit; but it's also been around since like version 1.0 and is still effective for consistent cross platform GUIs. LookAndFeel aside, Solaris, Windows, Linux (X11R6 and R7) and, I would presume, Macs all render the same under Swing. As a bonus, about five lines of code will make a Swing app an applet in any browser with a java plugin, and it still renders exactly the same.

I have no idea why something so proven would be deprecated after all this time, considering how many legacy apps could break. Unless I'm not understanding the rational, which is more than likely considering I've never bothered to follow up on it after reading the deprecation notice in the JavaDocs. If so, feel free to flame me for being so loud about something I was too lazy to look up before opening my mouth.