Slashdot Log In
Microsoft Rinses SOAP Out of SQL Server 2008
Posted by
timothy
on Wed Aug 27, 2008 03:50 PM
from the squish-splurtsch-splqlsh dept.
from the squish-splurtsch-splqlsh dept.
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."
Related Stories
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Use case? (Score:2)
Why exactly would you want a SOAP interface to SQL Server anyway? I mean, I wrote an XMLRPC interface for Visual FoxPro so that Unix machines could run SQL against it, but that was the only binding we had. It's not like there were other client libraries to pick from.
Re: (Score:2)
Why do you want a Microsoft SQL server anyway? (/ducks/)
Anyway - by using an application frontend to the database you will be able to do sanity checks on the access to the database thereby lowering the risk of inappropriate access to the database.
Lather, Rinse, Repeat (Score:4, Insightful)
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 [wikipedia.org] oriented API.
Re:Lather, Rinse, Repeat (Score:5, Funny)
SOAP (Simple Object Access Protocol)
Actually no: since SOAP version 1.2 SOAP is not an acronym anymore [w3.org] because it has nothing that is "simple".
Parent
Re: (Score:3, Funny)
Re: (Score:3, Funny)
At least you've got Java. I'm writing SOAP on PHP!
Well, it pays the bills...
Re:Lather, Rinse, Repeat (Score:5, Informative)
Actually, SOAP was pushed heavily by Microsoft as part of .NET. Java took a more holistic approach and created APIs for SOAP, XML-RPC, REST, and many other services. There are about 3-4 different ways you can do each of them, with two of them being official or semi-official. (The reason for the break is that the methodology for providing such services was greatly enhanced by the attribute tags added in Java 1.6.)
If you're doing SOAP services, I'd blame the market for slurping up Microsoft's push rather than blaming your tools which happen to support the standard.
What's the old saying? "It's a poor craftsman who blames his tools?" ;-)
Parent
Re:Lather, Rinse, Repeat (Score:5, Funny)
My girlfriend keeps insisting on me using SOAP before we interface - now I know its Microsofts fault.
Parent
Liar! (Score:2, Funny)
Re: (Score:2)
Re: (Score:2)
I'll get off your lawn now.
Re: (Score:3, Insightful)
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 (Score:4, Informative)
Only if you consider choice to be a bug. Personally, I like the fact that I don't have to use the officially sanctioned method if I don't want to. And the older official methods do not deprecate with the introduction of the newer methods. Both can still be used.
In fact, there is very little deprecated overall in Java. It's just that there is often more than one way to skin a cat. Choose the one that works best for you.
Parent
There is quite a bit of deprecation in javax.swing (Score:4, Insightful)
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.
Parent
Re: (Score:2)
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.
Classic comment on Java [slashdot.org] (specifically, I assume, J2EE...):-
"My hatred of Java has nothing to do with speed. The platform has become a giant morass of 'enterprisey' 'solutions' that create more need for more 'solutions'. And all Java 'solutions' must somehow involve XML, because it's standard, and enterprisey."
Re: (Score:2)
And I thought Java was the replacement to Perl because there was only one way to do it?
Re: (Score:2)
Actually, SOAP was pushed heavily by Microsoft as part of .NET. Java took a more holistic approach and created APIs for SOAP, XML-RPC, REST, and many other services. There are about 3-4 different ways you can do each of them, with two of them being official or semi-official. (The reason for the break is that the methodology for providing such services was greatly enhanced by the attribute tags added in Java 1.6.)
If you're doing SOAP services, I'd blame the market for slurping up Microsoft's push rather than blaming your tools which happen to support the standard.
What's the old saying? "It's a poor craftsman who blames his tools?" ;-)
Oh believe me, I know the genesis of SOAP, because I was there at its unveiling (of sorts), and I spoke to Don Box that day about it. It looked good to me at the time. How wrong I was. And MS was pushing it way before .Net came about. The presentation by Don was done on the MS campus.
As for the poor craftsman remark, I suppose so, but it's telling that the Java "community" embraced SOAP so whole-heartedly. Java people seem to have absolutely no eye for elegance whatsoever. I do think it's too bad the least
Re: (Score:2)
Re: (Score:2, Insightful)
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
Re: (Score:2)
As I type this, I'm slacking off from writing my own XML-based RPC framework, just because I want something simple. SOAP wasn't.
Re: (Score:3, Insightful)
Re: (Score:2)
I like XML-RPC for most things. It's not near as heavy as SOAP. If XML-RPC can't do what you need then you probably need to move away from an XML-based protocol.
Re: (Score:2)
Re: (Score:2)
OK so they win this round in Bullshit Bingo.
it won't be missed (Score:5, Informative)
Use a web server (Score:5, Insightful)
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: (Score:2, Funny)
Why is SQL Server even included in what God intended? ;)
Properly Layer Your Architecture (Score:2, Interesting)
No more SOAP-based Web services for your SQL Server database?
Of course you can have SOAP-based Web Services for your SQL Server Database. Make your application server handle them. Or your XML middleware if you use it. I don't know if SQL Server supports WDSL's, but if they do and your own SOAP interface is compatible, this ought not be terribly painful at all.
If one were to fall over, it ought to be because Microsoft is making their database a bit more secure by removing extraneous code that doesn't need
Confucius say (Score:5, Funny)
Confucius say "Microsoft wrong again. Computer programmers need more soap, not less."
REST to SOAP bridge (Score:2, Funny)
Uh-oh. (Score:2)
The point-of-sale package we sell mandates SOAP installation before it'll work. I wonder how badly this will bork their development/upgrade cycles...
Re: (Score:2)
Hey, it's the one person using the SOAP interface to SQL Server!
On a more serious note, do you have any idea why they did that, instead of putting an app server in front of it, or just connecting people to the database directly?
Poster's comment misleading (Score:5, Informative)
I think that poster's comment is a little misleading. From the article and linked materials it would appear that only integrated SOAP web services are deprecated, and not native XML as the poster implies.
Details of deprecated features here: http://technet.microsoft.com/en-us/library/ms143729.aspx [microsoft.com]
Why was this even included in the first place? (Score:5, Informative)
I don't get why Microsoft ever thought this was a good idea. Regardless of your opinion on SOAP (and I don't hate it nearly as much as some other folks here), having the SQL Server dishing it out directly was always kind of silly. Thats what a Web Server is for.
Removing silly code that just creates more places for security holes to hide is a good thing. Not doing it at all would have been better, but at least Microsoft is fixing that mistake now.
Re: (Score:2)
Once positioned as Java competitor (Score:3, Interesting)
I went to some MS conference years ago for a previous employer. The MS speaker who went over SOAP actually made it out to be a direct competitor to Java, which has never made any sense to me. But a lot of stuff from MS doesn't make a huge amount of sense to me.
SOAP (Score:3, Insightful)
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!!!
Re: (Score:2)
Re: (Score:2)
Except WSDL is as evil to look at as any XSD file I've seen and last I checked (which admitidly was many moons ago), Perl will not generate one based on your code and maintain it for you automagically.
Its not a problem making it work with different scripting languages
Correction. Most of them have good support for *consuming* other peoples SOAP service. Try to *create* a SOAP service in, say, Perl. I've never tried in other languages, but that is only because after trying in Perl, I swore off SOAP forever.
SOAP probably kicks some kind of alien psuedo-ass in a strongly typ
Re: (Score:2)
Re: (Score:2)
At the risk of sounding really stupid... if you're using SOAP over HTTP, why can't you use HTTP authentication and HTTP cookies?
(Meant as a serious question.)
Re:SOAP (Score:4, Interesting)
You can even create single purpose ssh keys which execute one command each
Close, but it is still not part of the specification itself.
Does javascript handle this? Can I use it in an AJAX call? Does it work out of the box from the CPAN libraries? Can you do it in PHP with a normal set of compile-time flags? Can you have anonymous clients authenticate themselves using a login/password (i.e. a flickr like web service?)
Want the ultimate proof that SOAP and XML-RPC is a failed specification? Every single javascript libraray (Prototype, jQuery, mooTools) doesn't support either one, yet every virtually every single XHttpRequest made is pretty much an RPC call.
Parent
what part of... (Score:3, Funny)
*lol*
/Mike
Why would you want SOAP in SQL Server? (Score:2, Insightful)
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.
Re: (Score:2)
BillG/SteveB gotta keep up with Larry...
Re: (Score:2)
Not unless they port SQL Server to Unix.
Proud Unix DB hippie, but the polo-wearing kind.
Re:oh great - Slightly OT Question (Score:2)
I'm a consultant currently forced to work in SQL Server. If you had to replace SQL Server with the nearest open source functional equivalent in *NIX, what would it (or they) be? I'm talking the whole nut - interface and underlying DB. I've used MySQL before, but only at the CLI. Is there a gui frontend I can use to show 'this is just like MS product, but better.. and free (as in freedom)' ?
Re: (Score:3, Informative)
First, MySQL is a toy. It's fundamentally braindamaged and you won't be happy migrating from SQL Server. Look at PostgreSQL which has much more functionality and is much faster in typical business settings. A lot of people like pgAdmin III for routine admin work; not having run an SQL Server before, I don't know how that compares to what you already know.
Re:oh great (Score:5, Funny)
Dude, take it back. There are some things that just aren't said in polite society.
Parent
Calm down, killer (Score:2)