Forgot your password?
typodupeerror
Databases Programming Software IT

Microsoft Rinses SOAP Out of SQL Server 2008 109

Posted by timothy
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."
This discussion has been archived. No new comments can be posted.

Microsoft Rinses SOAP Out of SQL Server 2008

Comments Filter:
  • 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.

    • by Z00L00K (682162)

      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.

      • 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?

  • by Jeremiah Cornelius (137) * on Wednesday August 27, 2008 @04:58PM (#24770445) Homepage Journal

    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)

      by abigor (540274)

      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)

        by 77Punker (673758)

        At least you've got Java. I'm writing SOAP on PHP!

        Well, it pays the bills...

      • by AKAImBatman (238306) * <akaimbatman@gmai[ ]om ['l.c' in gap]> on Wednesday August 27, 2008 @05:22PM (#24770709) Homepage Journal

        which probably explains why it was so enthusiastically adopted by Java

        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?" ;-)

        • by rishistar (662278) on Wednesday August 27, 2008 @06:28PM (#24771473) Homepage

          My girlfriend keeps insisting on me using SOAP before we interface - now I know its Microsofts fault.

          • Liar! (Score:2, Funny)

            by renegadesx (977007)
            This is slashdot... you dont have a girlfriend.
            • by jd (1658)
              Only on Slashdot could that be both insightful and correct.
              • by Gazzonyx (982402)
                You must be new... *checks ID* ...oh, nevermind.
                I'll get off your lawn now. :)
                • by jd (1658)

                  Young whippershnappers! Down't know what the wuuuurlds coming to. All these IP prints, all over my beautiful lawn!

        • Re: (Score:3, Insightful)

          by BillAtHRST (848238)
          "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.
          • by AKAImBatman (238306) * <akaimbatman@gmai[ ]om ['l.c' in gap]> on Wednesday August 27, 2008 @07:34PM (#24772423) Homepage Journal

            Isn't that the whole problem with Java in a nutshell?

            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.

            • by Gazzonyx (982402) on Thursday August 28, 2008 @05:21AM (#24776569)
              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.
              • The Serializable interface has been deprecated and will not be forward compatible

                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

                • My bad. java.io.Serializable is correct. I was misreading this warning from the JButton overview [sun.com]:

                  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,

                  • After re-re-reading it, I have no idea what they're trying to say

                    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

          • by Dogtanian (588974)

            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."

          • by dodobh (65811)

            And I thought Java was the replacement to Perl because there was only one way to do it?

        • if your supervisors/ bosses are tools then they rightly deserve the blame.
        • by abigor (540274)

          which probably explains why it was so enthusiastically adopted by Java

          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

          • Java people seem to have absolutely no eye for elegance whatsoever.

            Be fair; some Java people develop an eye for elegance. They just can't stay Java people after doing so.

          • And MS was pushing it way before .Net came about.

            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's telling that the Java "community" embraced SOAP so whole-heartedly.

            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

          • I disagree. Follow the progressions of a lot of tools. Struts is a beast. Newer Java web framework ideas like Spring are an improvement. Tapestry and Wicket are arguably even better.

            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.
        • by jd (1658)
          Java is OO, so the abstraction layer should hide the implementation details. At a high enough level of object abstraction, all communications classes in Java should look identical to the application - the compiler should optimize out the abstraction to make it efficient, not the programmer. Well, in theory.
        • Re: (Score:2, Insightful)

          by spotvt01 (626574)

          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

      • by lgw (121541)

        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.

      • by Anonymous Coward

        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.)

        • by zarthrag (650912)
          Googled "Shared Heuristic Access to Managed Protocols using Opensource Objects"....just in case - there are a few pages that actually use every word...scary
      • Re: (Score:3, Insightful)

        by jrumney (197329)
        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.
      • by MikeFM (12491)

        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.

    • by Simon (S2) (600188) on Wednesday August 27, 2008 @05:31PM (#24770805) Homepage

      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)

        by Forrest Kyle (955623)
        A coworker and I used to jokingly refer to it as "Stupid Obnoxious Asinine Protocol".
      • The problem with SOAP is that it is too underspecified to guarantee that all products can truly interoperate. When they finally make it complete enough to describe all of the interactions desired by vendors and their customers, they will find that they have rediscovered CORBA.

        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.
    • by iamacat (583406)

      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)

    by inmate (804874) on Wednesday August 27, 2008 @04:59PM (#24770449) Homepage
    as a developer on sql2005, i found very little use for it. the xml parsing and displaying functionality will remain in 2008, only the native xml webservices are being pulled. it made no sense anyway, it had nothing of the richness that asp.net web services offer and made most administrators nervous about its security (and rightly so!) why anyone in their right minds would have used it...i don't know!
  • Use a web server (Score:5, Insightful)

    by truthsearch (249536) on Wednesday August 27, 2008 @05:01PM (#24770473) Homepage Journal

    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.

  • 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

  • by Profane MuthaFucka (574406) <busheatskok@gmail.com> on Wednesday August 27, 2008 @05:19PM (#24770677) Homepage Journal

    Confucius say "Microsoft wrong again. Computer programmers need more soap, not less."

  • Now we'll just have to build an open source REST/SOAP bridge, if one doesn't already exist! ;)
  • 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...

    • by Jellybob (597204)

      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?

  • by code addict (312283) on Wednesday August 27, 2008 @05:49PM (#24770979)

    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]

  • by Tridus (79566) on Wednesday August 27, 2008 @06:35PM (#24771585) Homepage

    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.

    • by Degrees (220395)
      I understand your point, and agree that this simplifies the SQL server (which is a good thing). To answer your (implied) question though: SOAP was never a speed demon to begin with, so adding a middle-man in the form of a web server would (will?) likely make the speed dreadful. If you want fast access to the data, you want to talk to the box closest to the data.
    • by maashu (1356393)

      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

  • by Visoblast (15851) on Wednesday August 27, 2008 @08:27PM (#24773127) Homepage

    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)

    by coryking (104614) * on Wednesday August 27, 2008 @09:02PM (#24773515) Homepage Journal

    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!!!

    • SOAP sorta sucks as you and others have pointed out, but once you have the WSDL you're set. Its not a problem making it work with different scripting languages. They all have libraries. You just load the WSDL and go.
      • by coryking (104614) *

        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

        • Oh yes WSDL is evil as all heck, and IMHO XSD is at the root of it. Its really not that hard to do in most languages. Usually protocols are determined and infrequently changed. But at the end of the day, creating a WSDL and a XSD type hierarchy is more work that it really needs to be. Its one of those things that takes you a couple days to figure out the first time, but after that it only takes an hour or two for the second time. And believe me talking to someone using visual studio wax poetic on the merit
      • but once you have the WSDL you're set.

        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).

    • by Tridus (79566)

      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.)

      • by coryking (104614) *

        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.

    • 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.

  • SOAP being an open and vendor-independent standard, this is a very predictable move by M$. I wonder, did M$ ever successfully implement support for an open standard?
  • by mike_sucks (55259) on Wednesday August 27, 2008 @11:12PM (#24774579) Homepage

    ... the "WS-FAIL" spec didn't he read?

    *lol*

    /Mike

  • 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.

    • by Forbman (794277)

      BillG/SteveB gotta keep up with Larry...

    • "...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

  • 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.

  • ...SQL Server native SOAPs YOU!"

Aren't you glad you're not getting all the government you pay for now?

Working...