Microsoft Rinses SOAP Out of SQL Server 2008 109
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."
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.
Re: (Score:2)
Well, exactly. That's right up there with "telnet to the fileserver" as dumb ideas. If you're on the LAN, then there are far more efficient protocols for doing the same thing. If you're not on the LAN, why should you have straight access right into the DB?
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: (Score:1, Insightful)
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: (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?" ;-)
Re:Lather, Rinse, Repeat (Score:5, Funny)
My girlfriend keeps insisting on me using SOAP before we interface - now I know its Microsofts fault.
Liar! (Score:2, Funny)
Re: (Score:2)
Re: (Score:2)
I'll get off your lawn now.
Re: (Score:2)
Young whippershnappers! Down't know what the wuuuurlds coming to. All these IP prints, all over my beautiful lawn!
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.
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.
Re: (Score:2)
What in the world are you talking about? java.io.Serializable [sun.com], right? I don't see anything in there that says "deprecated".
This would be especially weird because Serializable doesn't do anything. It's just a marker for a class to say "Yes, I am serializable!" Now you may be able to accomplish the same thing with the new attribute tags, but I see nothing that prevents you from using the Serializable interface.
I think you may be
I stand corrected (Score:2)
Warning: Serialized objects of this class will not be compatible with future Swing releases. The current serialization support is appropriate for short term storage or RMI between applications running the same version of Swing. As of 1.4, support for long term storage of all JavaBeansTM has been added to the java.beans package. Please see XMLEncoder.
I've seen this warning on a few Swing classes. After re-re-reading it, I have no idea what they're trying to say, but I'm assuming its EE related (although in the SE Javadocs?). IIRC, RMI is Remote Method Invocation or something to the effect (affect? Arg!) of RPC... I haven't the foggiest what that has to do with short term storage.
At any rate, I stand corrected. Sorry for that rant. Given the chance,
Re: (Score:2)
Oh gosh, that's been there since the stone ages. All it means is that the *.ser format changes with each major release of the Java platform. Java is usually backward compatible with *.ser files, but it is not forward-compatible. Which means, for example, that Java 1.6 *.ser files cannot be read by Java 1.5.
In effect, nothing to write home about. And if you want to serialize Swing, you should probably use the XML Bean Serializer instead. You'll
Re: (Score:2)
That's the one (Score:2)
Effect can also be a verb... (Score:2)
As in: "Person X effected this change in policy.". The meaning is basically "make happen" or more literally "cause to happen".
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:1)
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)
Be fair; some Java people develop an eye for elegance. They just can't stay Java people after doing so.
Re: (Score:2)
You're quite correct about this. However, Microsoft's technologies at the time (based heavily on COM and DCOM) did not support SOAP very well. Thus it didn't see serious adoption until .NET hit the streets.
It might have been if this were true. But it's not. I was part of the JavaLobby forum (the Java advocacy meeting place at the time) and there was definitely a push-back against SOAP. A
Re: (Score:2)
EJB 2 was a nightmare. EJB 3 is much simpler and more logical.
Hibernate has had some growing pains, but is getting easier to configure without losing any of its massive flexibility.
The community is learning.
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:Lather, Rinse, Repeat = SHAMPOO! (Score:1, Funny)
Well yea, if you use SOAP in your hair it will get all nasty. SHAMPOO is better.
(Could stand for something like Shared Heuristic Access to Managed Protocols using Opensource Objects.)
Re: (Score:2)
Re: (Score:2)
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: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".
Re: (Score:3, Funny)
Re: (Score:2)
The same thing has happened with XML. The original XML spec was given out in a little blue-covered 20 page booklet at SGML 95. I would not be surprised today to find that the current XML spec is larger than the current SGML spec.
Re: (Score:2)
Ah, the irony. If you already decided to use XML and HTTP to communicate to your database, what's the big deal in avoiding SOAP? On the other hand, if you actually care about efficiency, why would you want to send <myvalue>12345678</myvalue> instead of a 4 byte integer? Yes, you can still have open schema and a tool to generate a human readable representation, even XML. The difference is just that you don't have to repeat that schema 1000 times in your document. Even for Javascript apps, a mini
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? ;)
Re: (Score:1, Redundant)
Re: (Score:2)
I loled, not redundant
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."
Re: (Score:1)
I, for one, welcome our new un-soaped Microsoft overlords.
Re: (Score:1, Insightful)
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.
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)
Re: (Score:1)
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.
Amen to this. DBA 101: - Limit your connections to the database. - Let the database do what the database is designed to do. - For the love of FSM, eliminate dynamic SQL. Cheers, -m
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)
Once upon a time, noobs looked at CORBA and said, "This is HARD!" So they set about re-creating it, poorly.
If you ever look at WSDL side-by-side with CORBA IDL, and compare call semantics, and compare on-the-wire load, and compare CPU load, you will quickly realize that XML RPC mechanisms are inferior in just about every way (including ease of use).
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.
Re: (Score:2)
I agree with the sentiments about a standardized mechanism for authentication, which makes me wonder why we don't see more use of the HTTP DIGEST model of authentication.
As I read your post asking about AJAX, JavaScript and PHP it seems to me that you are building web applications and using some form of HTTP client (probably a browser). Nearly all HTTP client packages I have seen support the HTTP DIGEST model. Once the credentials are set, each call to the server passes them along. Actually all of the HT
Re: (Score:2)
The problem is #1, not really #2.
We really like custom login forms and even in Web v0.2 (beta), people were using HTML and cookies to log into their CGI apps.
Both of the popular web servers (IIS & Apache) will let you hook their authentication/authorization phases. Both of them speak DIGEST and both will let you pass around blobs of goo so you can hook up your authentication and authorization handlers to your response handler.
You'd still have to come up with a way to customize the login form because no
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: (Score:2)
I've wondered that as well. You probably could, but you'be be doing crap underneath the SOAP level and thus would prevent some clients from using it.
If they had a way to keep a sesssion (like a session id via cookies)... oh man would life be easy.
Re: (Score:2)
I got around this in Ruby (for XML-RPC, talking to XML-RPC.NET) by generating the C# and Ruby interface code directly from a DSL, so that anyone connecting to the server with a browser can download a working interface definition directly into their project. Fun to do once, never again.
Very much M$ (Score:1)
Re: (Score:1)
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:1)
Does Oracle do this too?
Re: (Score:1)
"...Was Microsoft trying to make SQL Server be this uber thing that did web services, parsed XML, and served data..."
Answer: Yes.
In SQL2005, M$ allowed DBAs to create HTTP endpoints for URLs that exposes stored procedures over the web. You have to configure your web server to let it know that SQL2005 is the handler for that URL. Also in SQL2005 are native XML datatypes and XML columns (which have to be well-formed - you cannot store XML data in a SQL2005 XML column if an end tag is missing or the case
I think this made MS too open (Score:2)
Having SQL Server easily accessible by any front-end application would have meant that ASP.NET wouldn't have been a shoe-in for the front-end app. You could just have easily used PHP, Ruby, Python, Java, etc.
Just a hunch.
FTA: "In SQL Server 2008... (Score:2)
...SQL Server native SOAPs YOU!"
Re: (Score:2)
Not unless they port SQL Server to Unix.
Proud Unix DB hippie, but the polo-wearing kind.
Re:oh great (Score:5, Funny)
Dude, take it back. There are some things that just aren't said in polite society.
Calm down, killer (Score:2)
Re: (Score:2)
As mentioned above, I have to work with FoxPro (at a distance). You're too close for comfort.
Re: (Score:1)
I'll take FoxPro over MS-Access any day. MS-Access is mouse-centric, while Fox is keyboard-centric for development, meaning its easier to script it up.
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:2)
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: (Score:2)
There is a Windows GUI for MySql, there might be one for Unix, but I've never seen it, mostly I like to use phpMyAdmin for remote administration.
Re: (Score:2)
I don't know that it's as nice as the GUI tools for SQL Server or Oracle, but we've had no problems with it. You can graphically add and remove databases, tables, columns, foreign keys, and constraints. You can view the SQL used to create any table, sequence, view, or whatever. You can also view the database data in a graphical mode, and for any table with a primary key (which of course should be all of them) click into a column, change
Re: (Score:2)
Thanks for the insightful reply - yours was the most useful. I appreciate you taking the time to think and respond. I am downloading Postgresql and PGAdmin3 now to try out.
Much respect to you.
Re: (Score:2)
If you've been doing work in a real database like SQL server, you'll be much happier if you select another real database like PostgreSQL. MySQL is about the same as Access in terms of functionality, but with less reliability and interoperability. Sure MySQL claims to have stored procedures, views, triggers, foreign keys and other "enterprise database features that you dont really need", but every one of those "enterprise class features" has a set of disclaimers that would make Publishers Clearing House bl
Re: (Score:2)
Many thanks - I appreciate the insight, esp. regarding .NET. I am not terribly concerned with .NET though, as I will be using this for a personal project where I have the luxury of not having a bunch of .NET dependencies to worry about.
Which leads to another question - .NET is simply a MS framework, yet it gets a ton of play in discussion groups, etc. I'm relatively new to web dev work, so maybe I'm just ignorant, but why should I care about .NET integration, unless I have to do dev. work in someone else's
Re: (Score:1)
The only half-competent GUI I know of for MySQL is phpMyAdmin, but on the positive side, if you're trying to convince someone it's like using Microsoft that might be just what you need...