Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Microsoft Rinses SOAP Out of SQL Server 2008

timothy posted more than 6 years ago | from the squish-splurtsch-splqlsh dept.

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

cancel ×

109 comments

Sorry! There are no comments related to the filter you selected.

Use case? (1)

Just Some Guy (3352) | more than 6 years ago | (#24770415)

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:Use case? (1)

Z00L00K (682162) | more than 6 years ago | (#24775731)

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:Use case? (1)

Just Some Guy (3352) | more than 6 years ago | (#24777915)

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?

oh great (-1, Troll)

Anonymous Coward | more than 6 years ago | (#24770425)

so now my databases are gonna smell like a bunch of stinkin' hippies??

Re:oh great (1)

Just Some Guy (3352) | more than 6 years ago | (#24770477)

Not unless they port SQL Server to Unix.

Proud Unix DB hippie, but the polo-wearing kind.

Re:oh great (0)

Anonymous Coward | more than 6 years ago | (#24774069)

I spy with my little eye: an Oracle technician.

Re:oh great (4, Funny)

Just Some Guy (3352) | more than 6 years ago | (#24774287)

Dude, take it back. There are some things that just aren't said in polite society.

Calm down, killer (1)

Gazzonyx (982402) | more than 6 years ago | (#24776463)

Dude, chill. It's not like he said dBase IV admin.

Re:Calm down, killer (1)

Just Some Guy (3352) | more than 6 years ago | (#24777983)

As mentioned above, I have to work with FoxPro (at a distance). You're too close for comfort.

Re:oh great - Slightly OT Question (1)

OSXCPA (805476) | more than 6 years ago | (#24777111)

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:oh great - Slightly OT Question (1)

walshy007 (906710) | more than 6 years ago | (#24777593)

connect to mysql through odbc using openoffice base, it will give you an interface you like, very handy for those who are used to access-like front-ends,

Re:oh great - Slightly OT Question (2, Informative)

Just Some Guy (3352) | more than 6 years ago | (#24778137)

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 - Slightly OT Question (1)

tbannist (230135) | more than 6 years ago | (#24778141)

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:oh great - Slightly OT Question (1)

DuckDodgers (541817) | more than 6 years ago | (#24779301)

The pgAdmin 3 tool for PostgreSQL is a pretty nice graphical tool.

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 the value, and click save and the database automatically runs the corresponding update (using a primary key for the 'where').

And of course, you can run your SQL queries and copy and paste from the results or pipe them to a text or CSV file.

There's no convenient graphical tool for click-and-drag graphical generation of SQL queries, though. An experienced DBA doesn't need it, but newbies often get some benefit from tools like that.

I've heard that phpMyAdmin, a web-front end tool for administering MySQL, is at least as feature-full as pgAdmin3. But I've never used it.

Re:oh great - Slightly OT Question (1)

coryking (104614) | more than 6 years ago | (#24779335)

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

PgAdminIII is an excellent GUI that isn't as meaty as SQL Server Management Studio, but it gets most of your job done. It is still a bit more "gotta know SQL" centric though...

The big problem with PostgreSQL is that it isn't as well integrated into the .NET stuff as SQL Server (or Oracle). For example, if you like LINQ (and I like LINQ), there isn't much support for PostgreSQL. Lord knows about the ADO.NET entity framework. This is the most promising .NET stuff for now [devart.com] .

MySQL, as much as I hate it, has a bit better .NET integration. That is about the only thing it has going for it though... unless you consider pain and misery a feature.

Lather, Rinse, Repeat (3, Insightful)

Jeremiah Cornelius (137) | more than 6 years ago | (#24770445)

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 (1, Insightful)

abigor (540274) | more than 6 years ago | (#24770555)

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 (2, Funny)

77Punker (673758) | more than 6 years ago | (#24770689)

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

Well, it pays the bills...

Re:Lather, Rinse, Repeat (4, Informative)

AKAImBatman (238306) | more than 6 years ago | (#24770709)

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

Re:Lather, Rinse, Repeat (5, Funny)

rishistar (662278) | more than 6 years ago | (#24771473)

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

Liar! (2, Funny)

renegadesx (977007) | more than 6 years ago | (#24773911)

This is slashdot... you dont have a girlfriend.

Re:Liar! (1)

jd (1658) | more than 6 years ago | (#24774467)

Only on Slashdot could that be both insightful and correct.

Re:Liar! (1)

Gazzonyx (982402) | more than 6 years ago | (#24776599)

You must be new... *checks ID* ...oh, nevermind.
I'll get off your lawn now. :)

Re:Liar! (1)

jd (1658) | more than 6 years ago | (#24782069)

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

Re:Lather, Rinse, Repeat (3, Insightful)

BillAtHRST (848238) | more than 6 years ago | (#24771955)

"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 (3, Informative)

AKAImBatman (238306) | more than 6 years ago | (#24772423)

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.

There is quite a bit of deprecation in javax.swing (3, Insightful)

Gazzonyx (982402) | more than 6 years ago | (#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.

Re:There is quite a bit of deprecation in javax.sw (1)

AKAImBatman (238306) | more than 6 years ago | (#24777813)

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 confusing Serializable with something else. :-)

In any case, deprecated features in Java usually don't go away. They simply are not recommended for use any longer.

I stand corrected (1)

Gazzonyx (982402) | more than 6 years ago | (#24778375)

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, I'd do it again, but talk about the Thread class! =)

Re:I stand corrected (1)

AKAImBatman (238306) | more than 6 years ago | (#24778743)

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 get far more portable results than with native serialization.

Given the chance, I'd do it again, but talk about the Thread class!

*sigh* There is nothing wrong with the Thread class. Suggesting that programmers extend it rather than implementing Runnable was a foolish. There is no compelling reason to extend Thread other than early documentation that suggested it. And the stop() method seemed like a good idea at the time, but it wasn't. Calling stop() can have very negative consequences on running code that hits a critical state. (This is not a Java-specific issue.) You should ALWAYS use a flag to force the thread to exit naturally. If you do anything else, I will personally come over there and pummel you with a copy of the Java API specification!

Where do you work again? :-P

Re:There is quite a bit of deprecation in javax.sw (0)

Anonymous Coward | more than 6 years ago | (#24779737)

The Serializable interface has been deprecated and will not be forward compatible.

I just checked the latest javadoc for Serializable, and it's not marked as deprecated. Where do you get your info?

Re:There is quite a bit of deprecation in javax.sw (1)

Gazzonyx (982402) | more than 6 years ago | (#24781585)

See my reply to AKAImBatman (this thread); I misunderstood a warning note in the Javadocs.

Re:There is quite a bit of deprecation in javax.sw (0)

Anonymous Coward | more than 6 years ago | (#24779971)

Your original 'affects' was correct. Affect is a verb, effect is a noun. But they're both said the same you can always get the right meaning from context, and sooner or later they'll probably be interchangeable anyway. Anyway who cares.

Re:There is quite a bit of deprecation in javax.sw (0)

Anonymous Coward | more than 6 years ago | (#24781369)

I am not entirely sure what notice you may be referring to. I have never heard of any reference Serializable being deprecated. I highly doubt that this was the intent of what you read. To remove Serializable, at least four of the core API's would have to be completely re-written.

Just look at Collections and you'll quickly understand that to remove Serializable you would have to basically re-write Java.

I am guessing that you read one of the notes that are on many of Swings JavaDoc pages. They all basically say this:
"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."

(This was taken from the Java SE 6 JFrame page):

http://java.sun.com/javase/6/docs/api/javax/swing/JFrame.html [sun.com]

All this notice is talking about is that you should not save a Swing objects using Serializable methods then load that class after you have changed versions of the JVM I think this is pretty much a no brainier as far as any class goes. This is because there is no guarantee that the classes private variables have not changed between implementations.

If you it wasn't this kind of note, I would love to find out where you read it.

That's the one (1)

Gazzonyx (982402) | more than 6 years ago | (#24782197)

Yeah, that's exactly the one. I don't think that they worded as they wanted to, or I just changed the meaning around in my (admittedly poor) short term memory. Sorry about all the fuss, this was a case of me being a little too caffeinated and trigger happy with the 'reply' button =). Note to self: Order of operations; think... then post. Or, double check the facts before posting.

Re:Lather, Rinse, Repeat (0)

Anonymous Coward | more than 6 years ago | (#24776927)

so Java is like a weak version of Perl then?

Re:Lather, Rinse, Repeat (1)

Dogtanian (588974) | more than 6 years ago | (#24772761)

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:Lather, Rinse, Repeat (1)

dodobh (65811) | more than 6 years ago | (#24775665)

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

Re:Lather, Rinse, Repeat (1)

Brain Damaged Bogan (1006835) | more than 6 years ago | (#24773167)

if your supervisors/ bosses are tools then they rightly deserve the blame.

Re:Lather, Rinse, Repeat (1)

abigor (540274) | more than 6 years ago | (#24774407)

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 expressive and least interesting language of the past 30 years somehow got the server-side mindshare, but that's life. Other than a bit of grumbling now and again, I get up in the morning, fire up the old IDE, and get to work.

Re:Lather, Rinse, Repeat (1)

indifferent children (842621) | more than 6 years ago | (#24777501)

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.

Re:Lather, Rinse, Repeat (1)

AKAImBatman (238306) | more than 6 years ago | (#24778619)

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 lot of programmers felt it was far too complex and that Microsoft would use binary encoded Microsoft crudola to negate the multi-platform nature of SOAP. (Especially since the early versions of SOAP often did little more than wrap serialized COM information.) This lead directly to a push to use the simpler XML-RPC instead. (RMI was unsuitable due to the Java-specific nature of it, and CORBA was just a mess.)

XML-RPC had a short and fun little life as the preferred object communications protocol, but Microsoft's marketing machine was already convincing people to use SOAP. Without a strong competitor and with a push from the business side to support interop between Java and .NET, SOAP libraries began appearing. Most famous, obviously, is Apache's toolkit. It wasn't long after that Sun began the JSR to support SOAP. It was horribly late to the game, but the feeling was that if Java was going to do it, it should do it as best as it possibly could.

And I'll be damned if Java didn't take SOAP and make it its own. I was constantly frustrated with .NET developers I was working with because they were working around their tools rather than working with them, thus making everyone's lives harder. Yet on our side, we were able to tell the most junior guy in the company to go expose a predetermined list of interfaces and its was done lickety split and far superior to our .NET counterparts.

So in effect, Java's excellent support for SOAP was more about "do the job right or don't do it at all" rather than an overwhelming positive reaction to the technology. In fact, I don't think anyone in the Java camp ever quite warmed up to it. But it worked and there were bigger fish to fricassee.

Re:Lather, Rinse, Repeat (1)

DuckDodgers (541817) | more than 6 years ago | (#24779379)

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.

Re:Lather, Rinse, Repeat (0)

Anonymous Coward | more than 6 years ago | (#24785839)

They are learning things that the rest of the computing community learned in the 70s. That's hardly praiseworthy.

Re:Lather, Rinse, Repeat (1)

jd (1658) | more than 6 years ago | (#24774479)

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:Lather, Rinse, Repeat (2, Insightful)

spotvt01 (626574) | more than 6 years ago | (#24774603)

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.

Re:Lather, Rinse, Repeat (1)

lgw (121541) | more than 6 years ago | (#24770711)

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! (1, Funny)

Anonymous Coward | more than 6 years ago | (#24770743)

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:Lather, Rinse, Repeat = SHAMPOO! (1)

zarthrag (650912) | more than 6 years ago | (#24770767)

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:Lather, Rinse, Repeat = SHAMPOO! (1)

temcat (873475) | more than 6 years ago | (#24777027)

OK so they win this round in Bullshit Bingo.

Re:Lather, Rinse, Repeat (2, Insightful)

jrumney (197329) | more than 6 years ago | (#24774487)

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 (1)

MikeFM (12491) | more than 6 years ago | (#24775377)

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 (5, Funny)

Simon (S2) (600188) | more than 6 years ago | (#24770805)

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:Lather, Rinse, Repeat (2, Funny)

Forrest Kyle (955623) | more than 6 years ago | (#24775487)

A coworker and I used to jokingly refer to it as "Stupid Obnoxious Asinine Protocol".

Re:Lather, Rinse, Repeat (1)

Skjellifetti (561341) | more than 6 years ago | (#24782179)

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.

it won't be missed (5, Informative)

inmate (804874) | more than 6 years ago | (#24770449)

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 (5, Insightful)

truthsearch (249536) | more than 6 years ago | (#24770473)

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:Use a web server (1, Funny)

PitaBred (632671) | more than 6 years ago | (#24771245)

Why is SQL Server even included in what God intended? ;)

Re:Use a web server (0, Redundant)

riceboy50 (631755) | more than 6 years ago | (#24772009)

Chairs were thrown—it wasn't pretty.

The thought of (0)

Anonymous Coward | more than 6 years ago | (#24770505)

SQL Server showering is just not necessary...

Who cares ... (0)

Anonymous Coward | more than 6 years ago | (#24770507)

Who cares if SOAP is killed?
Who keeps the metric system down?
We do! We do!

Properly Layer Your Architecture (1, Interesting)

bill_mcgonigle (4333) | more than 6 years ago | (#24770553)

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 to be there. That's surprising, but welcome.

I suppose it's one less shortcut for developers, but one ought to expect there'd be a SOAP interface generator tool for sale to replace it for those who don't wish to do any coding. And if it exists, somebody out there is exposing their database directly to the Internet to save some effort. They've probably forgotten about SQLSlammer.

Confucius say (5, Funny)

Profane MuthaFucka (574406) | more than 6 years ago | (#24770677)

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

Re:Confucius say (1)

geirnord (150896) | more than 6 years ago | (#24784157)

I, for one, welcome our new un-soaped Microsoft overlords.

SOAP (0)

Anonymous Coward | more than 6 years ago | (#24770771)

SOAP plays into the Embrace, Extend, Extinguish model very well. It's large and complex enough that one company (not naming any names) could make small changes that make their competitors incompatible.

Unfortunately, if nobody jumps on-board your broken wagon, there is nothing to embrace or extend. So the only thing left is to extinguish; SOAP itself, that is.

Think about it... what can you tweak about something simple like JSON or REST that would let you get a competitive (some would say monopolistic) advantage?

It may explain why some companies (not naming any names) may not have adopted it.

Re:SOAP (1, Insightful)

Anonymous Coward | more than 6 years ago | (#24772647)

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.

Re:SOAP (0)

Anonymous Coward | more than 6 years ago | (#24775005)

Oh quiet you. They are just pissed because MySQL sucks and the only way to connect their Zealot Language to a real database server like SQL Server was through SOAP.

REST to SOAP bridge (2, Funny)

n4pcq (856464) | more than 6 years ago | (#24770867)

Now we'll just have to build an open source REST/SOAP bridge, if one doesn't already exist! ;)

Uh-oh. (1)

UncleTogie (1004853) | more than 6 years ago | (#24770925)

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:Uh-oh. (1)

Jellybob (597204) | more than 6 years ago | (#24776687)

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 (5, Informative)

code addict (312283) | more than 6 years ago | (#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]

Microsoft Rinses SOAP Out of SQL Server 2008... (0)

ksd1337 (1029386) | more than 6 years ago | (#24771109)

...because they dropped the soap. Now we know who the Goatse man was.

Why was this even included in the first place? (4, Informative)

Tridus (79566) | more than 6 years ago | (#24771585)

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:Why was this even included in the first place? (1)

Degrees (220395) | more than 6 years ago | (#24773819)

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.

Last Post (0, Offtopic)

B4light (1144317) | more than 6 years ago | (#24771907)

Last Post

Once positioned as Java competitor (3, Interesting)

Visoblast (15851) | more than 6 years ago | (#24773127)

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 (2, Insightful)

coryking (104614) | more than 6 years ago | (#24773515)

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:SOAP (1)

Bill, Shooter of Bul (629286) | more than 6 years ago | (#24774875)

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.

Re:SOAP (1)

coryking (104614) | more than 6 years ago | (#24774963)

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 typed language like Java or C# where the compiler can easily sues out your object model. Even then, since there is no standard for authentication or session management, you are left with only a hollow shell of a solution.

Re:SOAP (1)

Bill, Shooter of Bul (629286) | more than 6 years ago | (#24775075)

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 merits of SOAP is retarded. They didn't do anything and can't diagnose crap when something goes wrong, cause they never did anything in the first place.

I don't think SOAP kicks any kind of ass. We once interviewed a candidate that lectured us on why we were stupid for not accepting SOAP. Needless to say, they did not get the job.

I'm not sure we really disagree on anything, but its not impossible or too difficult to do in any language that has a library. Of course writing a library to do it, would be a PITA.

Re:SOAP (1)

indifferent children (842621) | more than 6 years ago | (#24777595)

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

Re:SOAP (0)

Anonymous Coward | more than 6 years ago | (#24775065)

There is a very simple and standard way of doing RPC with strong authentication: SSH calls. You can even create single purpose ssh keys which execute one command each. The ssh also forwards the standard input from the RPC client's computer to the RPC host, allowing for transfer of all kinds of data, including XML files.

Re:SOAP (3, Interesting)

coryking (104614) | more than 6 years ago | (#24775219)

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:SOAP (1)

dwarfking (95773) | more than 6 years ago | (#24778339)

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 HTTP authentication models do this, DIGEST happens to be more secure.

But nearly everyone avoids these for two reasons:

  1. They can't have custom login forms and must rely on the client to prompt for the credentials
  2. Specifically with a browser, there is not real log out mechanism

There are some javascript tricks that can be performed with various browsers that will clear the credential cache so it isn't impossible to log out, just painful.

Then, because each call to the server passes the credentials, there is no need for cookies or the like to key off of to find any server side session state, just the user id.

The nice part about this model is that the credentials are part of the communication protocol handler, not the application, so once set in the client, each and every HTTP call, from any of the application libraries, will use them, and most proxies don't cause problems either.

Couple that with ACLs on specific URLs (REST model) and you have something similar to the J2EE container managed authorizations allowing access to services.

Another benefit is that since it is the HTTPD that is performing the authentication checks, and not an application server processing a form, it is easier to protect the network. The HTTPD can live in the DMZ and only requires access to an authentication system like an LDAP directory server to confirm credentials, and the app server lives behind a firewall. No calls make it out of the DMZ without being authenticated.

Nearly all form based authentications I have encountered require the posts be passed through the DMZ to the back end for processing, basically meaning you have non-authenticated access to the application server making the DMZ pretty much irrelevant.

Re:SOAP (1)

coryking (104614) | more than 6 years ago | (#24778983)

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 nobody likes the browser ones. I'm not sure how this part would work because as you say, DIGEST authentication requires the browser popup up it's own dialogs.

I actually think there is one more catch. Who does the hashing of the password? Obviously you dont want the client to give you a plaintext password. I'll have to look into this as I recall there being a way to get it to do MD5. If so, unless you are starting fresh, what do you do with the existing 20,000 users passwords in your database who are hashed some other way?

When you look at it... I think the way we handle our authentication/authorization on the web is the perfect blend of built-in and roll-your-own. It is easy to understand, easy to customize and our languages and frameworks offer a fairly standard way to manage things.

The fun problem is the "web way" of doing authentication/authorization breaks down the second you toss "real" applications in the mix. Have fun getting your client-side "real" program.exe talking with any kind of web service that uses HTTP cookies for session and HTML forms to log in. They are easy(er) if you use DIGEST though :-)

Re:SOAP (1)

Tridus (79566) | more than 6 years ago | (#24776693)

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 (1)

coryking (104614) | more than 6 years ago | (#24778225)

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:SOAP (1)

RegularFry (137639) | more than 6 years ago | (#24778973)

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$ (1)

BhaKi (1316335) | more than 6 years ago | (#24773989)

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?

Re:Very much M$ (0)

Anonymous Coward | more than 6 years ago | (#24774857)

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?

MS were on all the committees that developed SOAP. All of the key docs have Microsoft contributors. They *wrote* the open standard.

Re:Very much M$ (1)

BhaKi (1316335) | more than 6 years ago | (#24775735)

They did write it. But they don't implement it properly.

what part of... (2, Funny)

mike_sucks (55259) | more than 6 years ago | (#24774579)

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

*lol*

/Mike

Why would you want SOAP in SQL Server? (2, Insightful)

MobyDisk (75490) | more than 6 years ago | (#24774647)

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:Why would you want SOAP in SQL Server? (1)

Forbman (794277) | more than 6 years ago | (#24775637)

BillG/SteveB gotta keep up with Larry...

Re:Why would you want SOAP in SQL Server? (1)

MobyDisk (75490) | more than 6 years ago | (#24777197)

Does Oracle do this too?

Re:Why would you want SOAP in SQL Server? (1)

Not The Real Me (538784) | more than 6 years ago | (#24781383)

"...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 does not match). Within SQL2005, if you're querying an XML column you have to use XQuery. And yes, select statements can return results formatted in XML.

Web Services are deprecated in VS 2008 (0)

Anonymous Coward | more than 6 years ago | (#24779781)

The push is to wrap them in WCF service contracts, oldschool web references are buried deep in the "add service reference" dialogs.

Get with the f*cking times. This is no cause for nerd rage.

This was "news" a year ago, btw. I'm shocked it took this

Prison reference? (0)

Anonymous Coward | more than 6 years ago | (#24783407)

What?
MS Dropped the soap?

I think this made MS too open (1)

mgkimsal2 (200677) | more than 6 years ago | (#24784613)

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

Mr. Firewall (578517) | more than 6 years ago | (#24786305)

...SQL Server native SOAPs YOU!"

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?