The Opportunity of SOAP

A reader writes: "There's an interesting piece on DaveNet concerning SOAP and some of Dave's predictions for it. He also talks about SOAP being in a flexible phrase, and the potentials for it, if it is used correctly. The point about the multiplicity of Dot.Nets is a good mental exercise too. Will development happen that way?"

Comments

On hold with Microsoft for 6 months

[cworley]

Dave sez: "Microsoft says they love developers"

I have an example:

I remember when NT4 first came out, trying to use their documented "Streams" support.

Nothing the MS NT4 documentation said was accurate. Files that were supposed to exist didn't, functionality claimed wasn't there.

So, I paid for Microsoft support on the issue.

The MS flunky couldn't answer my questions... said only developers could, and they were busy trying to release NT5 (which sliped schedule for another 3 years, finally released as W2K).

He said he would keep trying to get an answer, but after six months, I asked for my money back, and haven't used a Microsoft product since.

Re:On hold with Microsoft for 6 months

[cworley]

>which is one instance of a dissatisfied Windows developer

One of many; and MS is better at screwing outside developers than any other OS maker.

You keep trying to belittle a truly deplorable situation, and stick up for MS beyond all belief; any normal developer would not stand up for MS like this. Have you had a similar experience with another OS vendor? I've worked with Windows since 2.0 -- I have many similar experiences, but none over the last three years -- I don't do WinDoh's anymore. I've worked with a dozen OS's in the last 20 years, and have never experienced this bad of treatment from any other vendor.

Do you work for Microsoft? Why the AC? I've been noticing a lot of pro-microsoft trolls on /. lately. Is this a concerted effort from Ballmer?

>Altura developed a Winsock implementation for the Macintosh

So they have one instance where some misguided company has implemented a MS API on another OS (so many have tried and failed). Poor Altura now has obliged itself to endlessly chase Microsoft's tail.

>you don't know what 'proprietary' means.

You can mince words all you like, but MS controls the API, modified it from the industry standard, and keeps the source secret -- the standard way they abuse their power to assure that they maintain control of the desktop.

Re:On hold with Microsoft for 6 months

[cworley]

>Okay, now I see you don't know what 'proprietary' means. You can find the definition here:
http://www.dictionary.com/cgi-bin/dict.pl?term=pro prietary

What a hoot! LOL! I quote verbatim from the above link:

proprietary
...
2. In the language of hackers and users, inferior; implies a product not conforming to open-systems standards, and thus one that puts the customer at the mercy of a vendor who can inflate service and upgrade charges after the initial sale has locked the customer in.

Did you read the link you supplied?

I do (and did) know what proprietary means after all! Thankyou for clarifying that!

Re:On hold with Microsoft for 6 months

[cworley]

>yes, I do work for Microsoft
...
>FALSE (Winsock is a public standard which can be implemented by anyone, and non-Microsoft implementations are available)

Now it makes sense... you know what you're saying hides the truth; you're just spouting the "innocent me" company line.

I guess if you make enough money you can convince yourself that your company's crimes are justified.

You keep trying to divert attention to "the open API" when I continuously reiterate that your source for that API is closed.

And that makes all the difference in the world, even if you won't admit it to yourself.

For example, before MS integrated Winsock and a PPP client into Windows, Trumpet had market share. They had a great product. The moment MS integrated Winsock and PPP into their OS, Trumpet was a has-been; anybody with a competing Winsock or winsock application atop windows can only fill small niche markets. You didn't have to do a better job, you just had to bundle it and you won.

MS's lawyers were obfuscating the trial last week saying "Every other monopoly in history has been built on acquisitions". The judges were even buying into this fact.

Microsoft didn't need to acquire companies to build their monopoly... all they had to do was 1) bundle their competing version of the product with the OS, and 2) create hooks between their applications and the OS that weren't exposed API's for outside developers.

Bundled Winsock and an integrated PPP (using non-exposed hooks into the OS) were all Microsoft needed to supplant Trumpet. Trumpet couldn't compete. They made the market for Microsoft, and had to fall on the sword for Microsoft.

This is the standard method MS uses to leverage its monopoly power to kill competition.

This is a bad example in that sockets and PPP should have been part of the OS all along -- they are a standard OS feature that MS wasn't supporting. It's a shame good companies die just because you weren't supplying the customer a necessary OS feature (which a browser is not, I digress).

If Microsoft ever feels it's platform is threatened by Altura or anybody making a competing Winsock, all they have to do is modify their proprietary source. It doesn't matter if they screw the open API in the process... everybody has to chase Microsofts tail and become compliant with MS's changes. Microsoft can and has changed it's API's like this. The net result is, customers blame the folks whose products got screwed then realize they have to buy the application from Microsoft. It's a viscous cycle, I'm sure Ballmer laughs all the way to the bank.

That's how Microsoft uses it's monopoly power to stop competition. That's documented in your conviction, and the "Findings of Fact" are not under contention in the appeal... only the remedy.

You can't admit you're wrong... then you'd have to admit your livelyhood is tainted. So, keep on those rose-colored glasses.

Re:On hold with Microsoft for 6 months

[cworley]

>I decided to do a quick search for "Streams Environment" and "Windows". The result included products which use the Streams Environment on NT 3.5x and NT 4.0

You're putting words in my mouth. I did not say that "MS discontinued Streams but documented otherwise".

As I originally stated:

I paid for Microsoft service concerning the fact that the documentation Microsoft provided with NT4.0 concerning Streams was clearly wrong.

You and others said "it was discontinued"... I stated that I just quit using Windows altogether soon after I was put on hold for six months.

> ...that doesn't justify the poor service you claim to have experienced.

Exactly the point of this thread. Thank you.

And the problems were not my user errors... the documentation was clearly wrong. As I recall, It looked as though Microsoft had prepared the documentation by changing all occurrences of "NT3.51" to "NT4.0", while they had actually changed many parts of the interface altogether.

Had this been open source, I could have referenced the source and figured out the changes myself... but that's another story.

>However, if you were as hostile and dishonest as you've been in your posts here...

The fellow assigned to the call, although poorly trained in the OS he was servicing, was very cordial. I'm adult enough to not kill the messenger; I too wanted this problem solved. We got along quite well, and he seemed truly interested in resolving the issue, even though the developer managers he was trying to get help from would not give him the time of day. He was as frustrated as I was but neither had harsh words for the other... in fact I think we commiserated over this issue. We got along quite well, and after the call was closed (with a refund), Microsoft called me to eveluate his performance: I told them he was very good, and just needed suport from developers.

You shouldn't be making such statements without a bit of knowledge. You work for Microsoft... just look up the call and see what transpired and publish it here!

Remember, I was trying to build a product. My hope was this problem would be solved. It probably was eventually, but by then, I'd quit using Windows altogether.

"Hostile" is too brazen an adjective for my behavior in this post. "Direct" would be more appropriate, but I won't mince words and accept "hostile" if that's what you prefer. Posts, in general, lack the inflections of normal speech, and can easily be taken wrong. You probably haven't been on the internet long enough to see a really hostile discussion; this isn't one of them ;)

"Dishonest" is truly uncalled for. I am not a liar. I have eye witnessed the events I've relayed, and have communicated them as I saw them.

I believe you call me a liar to help you justify your company's behavior. I don't know you personally, but that's the only reason I can imagine that you would defend Microsoft's behavior and blame the victim instead.

Re:On hold with Microsoft for 6 months

[cworley]

>AT&T and Sun said they only wanted to "unify" UNIX, but nobody else believed them.

I did ;)

Your references are quite good... we may never know if Sun truly intended to unify or splinter.

Microsoft loves to point out this "Balkanization of Unix" to justify it's tyranical monopoly.

I have to agree (but find Open Source is the solution, not a tyranical monopoly).

Any consortium of vendors is at one moment patting each other in the back, and the next moment stabbing each other in the back.

Whether it's the tyranical monopoly or the divisive consortiums, the problem's they cause for a truly competitve computer/software marketplace is due to their desire to increase their bottom line by locking customers in to proprietary hardware/software.

If Microsoft weren't interested in it's profits, then it wouldn't use it's monopolistic position to put competitors out of business. Likewise, if consortium members didn't keep a hidden agenda for making profits from the groups protocol/standard/whatever, then we'd see complience and true competition between vendors (who can make the best/cheapest product, rather than who can better lock their customers in).

You can't fault them for the profit motive. You just can't put them in charge of the standards if you want to see healthy competition.

In Linux, trusted engineers make the specifications, open for all to comment and criticize. You can fault their judgement, but you can't fault their motives.

Letting Open Source itch scratchers drive the standards would be the best for competition in the computer marketplace.

Maybe that solution would have satisfied the appeal court judges.

Re:On hold with Microsoft for 6 months

[cworley]

The problem with Winsock is it's proprietary API. Of course, that's not a problem for Microsoft; it helps assure that their customers are bound to their platform.

Although I don't agree that "Streams was a failure for everyone" -- it's a matter of opinion. In my case, I was using streams for portability of device drivers... a non-standard high speed serial interface that may contain IP data. Their RAS was the closest supported entry point, but they assumed you were using a slow serial interface and added many unnecessary software layers. But, I digress.

Anyway...

The point was, they said they supported it, and they didn't, and they didn't have enough respect for their customers to say "It really isn't supported".

I too now share Microsoft's lack of respect for their customers ;)

Re:On hold with Microsoft for 6 months

[cworley]

>Funny, I looked in the Microsoft Knowledge Base...

Your "Knowledge Base" quote says nothing of discontinuing Streams support... it only says they made TCP/IP "better". For Microsoft, that usually means "Our OS is once again guaranteed not to work with any of our competitors applications".

The SDK/DDK documtntation supplied with NT4, after NT4 was released to the public, still claimed streams support.

As for Sun's switch to System V... that was an effort to unify with other Unix vendors. They worked long and hard on assuring compatibility between the old SUNOS and the new Solaris.

They didn't just change the API's to screw outside developers, as Microsoft does.

Re:On hold with Microsoft for 6 months

[connorbd]

Streams was a failure for everyone, I think. Apple jumped on the bandwagon too; they got a drastically improved network architecture out of it, but when the Next deal went down they eventually realized that sockets was the lingua franca of network programming. No streams in OS X (unless you're still writing for Classic, that is).

/Brian

Re:On hold with Microsoft for 6 months

[cworley]

>PS If you think the transition from SunOS 4 (BSD) to SunOS 5 (System V) was painless, I suspect you weren't a SunOS 4 user.

On the contrary, I was a user.

Do you have any confirmation to back up your version of the story? I'd be interested to know if this were true.

Re:On hold with Microsoft for 6 months

[cworley]

>Microsoft's decision to convert NT from Streams to sockets was a move in the right direction

You're still missing the point: they said they supported it. It doesn't matter if streams are good or bad in your opinion. Saying they support something they don't shows what they think of developers; not admiting they don't support it makes it worse.

On your topic: both could have been supported. Finally, Winsock is a proprietary API. A proprietary API is not good for developers, only good for a company trying to lock you in to their closed platform.

Re:On hold with Microsoft for 6 months

[cworley]

>I remember the big hype of NT 3.5 was that they were dumping Streams and moving to the more standard (win)Socket interface.

Maybe it was dumped (I've never looked back to find out).

The problem was, all their relevant NT4 SDK/DDK documentation said it was still supported. I would have liked to hold their feet to the fire and make them implement the API's they said they exposed. But, I'm just a developer, and Microsoft hates developers (that don't develop apps for MS).

My guess is, it had been dumped, and they didn't bother to update the documentation.

Their streams support was lame. Nothing like Solaris. It wasn't just it's documented lack of robustness and completeness, but its extremely poor performance.

I think this was on purpose: they needed "Streams" support to get government contracts. Once they got the contracts, they could pull a bait-and-switch and force the idiots (who made the decision to switch to Microsoft) to cover their asses by rewriting their code to use Microsoft proprietary protocols.

Re:On hold with Microsoft for 6 months

[cworley]

>I don't defend incorrect documentation

They're guilty of more than incorrect documentation. After six months with an open service call, they couldn't even tell me "oops... that section of the documentation is a mistake -- we really don't support it any more".

This example was to give more anecdotal evidence concerning Dave's point about what Microsoft thinks of outside developers.

Back to your digression:

>Windows Sockets is not a proprietary API

Does it work on other operating systems?

Is it Open Source?

No and no, therefor it's proprietary... meant to lock your application onto their OS, and break your application at their whim.

>so this should not be surprising

I'm never surprised by this tactic; I've come to expect it from Microsoft.

Re:On hold with Microsoft for 6 months

[cworley]

>Maybe you'll believe the FAQ?

I partly agree with all those points. I too liked SunOS better than Solaris, but I was not against change just because it required that I learn something new. I kept existing projects on SunOS, and put new projects on Solaris, and eventually became as familiar with Solaris as I had been with SunOS (all of which I've forgotton, since I only work with Linux now -- that too took a learning curve).

The problem is, that FAQ doesn't support the claim that: "Solaris was Sun and AT&T's way to drive a wedge between the Unix vendors", vs. my claim that Solaris was an attempt to Unify the vendors.

I'm not saying you're wrong, I just need more proof before I change my mind, and your position (this assumes you're the same AC) is not discussed in that FAQ you mentioned.

Re:Virtual Person?

[AdmrlNxn]

I do believe you can't troll whilst under a pussy ID. (IE Anonymous Coward) So your troll has been denied.

~AdmrlNxn
Whistler is to Zeus as Linux is to Hercules

Re:Yet he forgot...

[scrytch]

Biztalk is an application. It defines a number of XML schemas which map onto the same concepts as EDI, like purchase orders and manufacturing requests. It includes mechanisms for description and discovery (UDDI) of such schemas, as well as various transports to transmit them. Biztalk is there to replace EDI (and if you've used EDI, you'll raise quite a cheer at the prospect of its demise)

SOAP is a wire protocol. It applies the XML schema types to arbitrary data and provides some basic messaging on top of it, such as envelopes, metadata, and named endpoints. It's hardly even a protocol, much less a full-blown application.

But don't let me stand in the way of gratuitous microsoft bashing or anything.
--

Re:Um...

[embo]

I think it's brilliant. Now I can create large scale solutions and distribute out my application logic layer to dedicated object servers between my front end and my database. When my servers are getting too much load, I just add another object server, only this time it's easier to add because I know I have many solutions for getting HTTP working to transport my object calls. I can bind soap to any port I want, not just port 80. I can firewall off the front end, and additionally put a firewall between the front end and my object servers, and do IP restrictions with IPChains and/or Apache so that only MY front end servers can access the SOAP objects on the object servers. There's no reason to use port 80 for ANY of this. Want greater security? Use an SSH pipe to redirect all your HTTP calls over SSH.

By using SOAP, I no longer have to fight with marshalling or any other headaches, because I'm using a protocol that I know works with very little fuss, and I can concentrate on writing objects instead of worrying about interoperability. Plus, I can write my objects in PERL, Python, C, C++, hell you could probably even write a wrapper for a BASH script. If, God forbid, you need to access VB objects from your Linux application, you can now do that.

I think this is a marvelous thing, and as long as you take some security precautions, I don't see any problems. If you are opening up your HTTP port to the world and you are running a SOAP object on that HTTP port, then stupidity is your crime, and your sentence will be executed appropriately.

Re:Microsoft lost control of SOAP :)

[SoftwareJanitor]

Who has no idea? You say Microsoft was the "primary contributor" to XML, but Jon Bosak of Sun was the leader of the working group creating XML... Eh? Hey, I never said that Microsoft wasn't involved with the design of SOAP or XML, but really, either its an open protocol or it isn't. I never said IBM's contributors made changes that Microsoft wasn't aware of, but that doesn't mean they were changes that Microsoft would have proposed without prodding by IBM either.

Of course, raving, conspiracy-loving zealots never let little things like facts get in the way of their theories.

Pot, kettle? At least I'm not an Anonymous Coward.

GAGA For Bubble Technologies

[joubin]

There seems to be a great deal of confusion regarding xml-based point-to-point request/reply mechanisms such as SOAP (and its precedent XML-RPC). This type of mechanism has been identified, explored, developed, and deployed over the past 3 decades in various forms and realizations. That the preceding sentence is necessitated where 'well-understood' would have been sufficient is indicative of the general developer confusion in the debates on these techniques. And what is specially puzzling is the apparent weak-grasp of authors of such protocols on the issues involved.

Lets clear the smoke.

If "two" (forget more for a second) "alien-things" happened to agree to use a messaging protocol, such as SOAP, well, right there we would have a minor (but cosmic , considering that "alien-things" are involved) miracle , since apparently they communicated their agreement without a common communication means. (No. Telepathy doesn't count.)

Smoke: XML messaging (SOAP) works miracles!

Fact: "[A]lien-things" first need a common mechanism for reaching consensus regarding communication of information..

So lets say they belong to the Inter-Galactic Alliance of Geeky "Alien-Things" [I-GAGA-T(TM)], governed by the I-GAGA-T's strict policies regarding communication means deployment. [Kinda like the saying "lets all use HTTP"]. Then, our two brave "alien-things", charter members of I-GAGA-T (affectionately known to each other as GAGAs), decide to communicate using SOAP, at which point they have fulfilled "the ONLY requirement when doing client/server" according to their recently hired communication consultant, an Earthling named garoush . [Believe me folks, I am not making this up. A true story from the GAGA archives.]

But have they?

No. One of the GAGAs decides to send a message using SOAP to its newly acquired friend! So the trusty (and somewhat rusty) SOAP client is fired up and the message is sent. And guess what? Promptly comes the standard error reply: "Message received, NOT understood. Ca va?"

Put simply, using SOAP, two or more 'alien-things' can communicate to each other as long as they agree on the SOAP protocol - which is the ONLY requirement when doing client/server using SOAP.

So, put simply, the above is a false statement.

[And this point in the story, we find an agitated and nervous garoush, furiously sending SOAPy messages to Earth: "<help>Me!!</help>" -- Lets hope that back on Earth, garoush's friends have first agreed on the Rescue-Message-Format! (But maybe they didn't, hey garoush? "Just use SOAP" he used to say back on Earth. Well ... Just use SOAP then :) )]

SOAP, and XML-RPC, both provide a means for one GAGA to send messages to another GAGA, even if the two GAGA have discovered each other for the very first time. And this messaging protocol , based on the well-understood [there!] request-reply paradigm, and utilizing a standard XML-based message container , delivers SOAP-compliant XML messages from the sender to the receiver.

So as garoush learned/will-learn [funny thing, this space-time continuum] from his consulting gig to the GAGAs, <help>Me!</help> is not defined. For the content of the message, which delivers information from garoush back to Earth, to be understood by the recipient's), he and his hoped-for-rescuers would have first needed to agree on the format of encoding information in your SOAPy messages.

Sure CORBA, DCOM, COM+, Java, etc. allow you to enable two different components to talk to each other, but those technologies do it in such a way that you must have a 'piece' of the server (called the client) to be delivered and used by the client developer. Thus, to talk with a 'server' you must meet the needs of the 'server' when using CORBA, DCOM, COM+, Java, etc. With SOAP, this is all eliminated. As long as the server publishes its API via the SOAP protocol, I can write my client to talk with the server using what ever I want. This frees me from having to 'embed' in my client a piece of the server -- thus there is no longer any 'hard-coupling' between two 'things'.

[We'll skip the fact that SOAP, CORBA, [D]COM[+], and "Java" are a rather orthogonal set of technologies ...]

What is apparently not understood by garoush is that CORBA, DCOM, COM+, Java RMI, do much much more than just simply pass messages from one GAGA to another. [I recommend this great book written specifically for GAGAs for more information on what real (i.e. working) Inter-GAGA Communication Protocols require to function. (Check out the GAGAs on the cover!)] .

Lets just take Java's RMI as an example. What's this with RMI you say? Why didn't they call it Java RPC? I'm glad you asked. See the 'M' in RMI? That's a method, which is a procedure bound to an object. The P in RPC refers to a procedure, which is not necessarily bound to anything. To invoke a method of an object, you first need to get a handle on the object, a remote reference. Any object you say? No. Objects which have been registered with a Registry/Directory Service ( UDDI anyone?) Then you pass the method invocation message to the remote object and a bit of infrastructure on the receiving end maps your method invocation message to an actual method call on the specific object you are invoking. This sub-process of mapping your messages to actual method calls on a specific object uses a messaging protocol which is analogous to what SOAP specifies.

So:

Smoke: SOAP (& XML-RPC) are distributed object technologies! [This goes beyond Smoke and verges on GAGA humor..]

Fact: SOAP is a Simple Xml-based Messaging Protocol (SXMP)

Fact: By the time you have implemented a true Simple Object Access Protocol using a SXMP, you will have something that will look awfully close to RMI. (With the exception that RMI doesn't shuffle needlessly verbose ASCII bits through its system-level plumbing, but your SOAP does.)

In short, by the time you have provided the functionality of an RMI mechanism, such as Java RMI, using SOAP (or any RPC mechanism), you will have accomplished, by the prerequisite functionality of the task at hand, a fairly complex bit of software engineering. Congratulations! (CORBA? Oh boy ...)

In short, using SOAP, we now enable a true 'smart' data-exchange-protocol between two systems such that development is now at the level of "data-exchange" rather than API, SDK, language, etc.

No. More likely, you will realize that having standardized on the data-exchange, you have in effect delegated the complexity of building a distributed object system to the client as opposed to the infrastructure.

Now that is smart. [Good going there Bill!]

[Meanwhile, back on Earth, garoush's friends and would-be rescuers [will] happen upon a long forgotten SOAP Server log file. There, buried among other debug and error messages is the messaging logging the error message the SOAP server sent back to garoush back on planet X. "Ouch" says one of garoush's friends. "I hope he is OK". Now, isn't it just great that XML messages are human readable? (Its too back Servers aren't human -- damn shameful waste of all that human readable information!)]

Smoke: SOAP/XML is a great leap forward!

Fact: Bubble Economies produce Bubble Technologies .

Re:GAGA For Bubble Technologies

[garoush]

Nice post, but you are missing the big picture so I have to try on last time but first you must agree that how those two 'alien-things' find each other and connect is not the job of SOAP/XML. This is a different problem that must be solved by some other means for which a lot of way excits.

Now let me try again... and see if joubin realy understands SOAP and its buseinss value.

Lets say I came up with a new device imbedded in my watch and this device wants a simple service from a server (lets say the weather for NY city or any other city from my limited selections). Lets say there is a server that provides such a service but this server provides an SDK/API based client based on CORBA, Java, etc. So if my limited device wants to get the service out of the server, it must implement the server's SDK/API requirement.

While this is not a problem in a fully fledge environment, it is a serious requirement for my limited device. The only way I can address this problem is create my own server, which acts as a gateway between the real server and my device. A doable solution but unnecessary in the universe of SOAP/XML.

If you think about the problem that I presented and you extend it to other 'services' you will see that SOAP (and XML) is the answer. Lets face, it EDI (if you don't known what that is and it's importance within Fortune 100 companies than you will never understand SOAP or XML) is what used today as the primarily means of exchanging 'smart' data between two or more trading partners that include banks. EDI has a lot of limitations, XML and SOAP will fix all this.


---------------
Sig
abbr.

Re:Um...( a little more detai on what SOAP is)

[dbrower]

You fell into the trap-- language bindings are not the protocol. You can complain about the weight of the corba language bindings, but what about its protocol is 'heavy weight' compared to the protocol used by SOAP? There's only a handful of messages in IIOP -- not much different than SOAP.

I still don't get what makes SOAP a "lightweight protocol".

-dB

J2EE is a sub-set of .NET

[joubin]

As in bricks are a sub-set of a building.

(And if Sun had really undestood the business model behind .NET, Java would have been handed off to a standards body, and there would be no XML.)

Re:SOAP on a ROPE

[jon_c]

Don't forget COM+'s new TNA apartment model. -Jon

Streamripper

Re:Um...

[Dionysus]

My understanding is that v1.0 of the specs specified http as the protocol, and version v1.1 got rid of that specification. I don't think v1.1 of the specifications are out yet (might be wrong).

Soap Use

[Anonymous Coward]

I wish more Linux evangelists would use Soap.

After all, 5 minutes once a day with Soap will do wonders for your interpersonal skills!

Re:Um...

[joubin]

As you know, Islam prohibits the depictions of the human form in photographs, in statues or in paintings.

You shouldn't believe everything that you read in the press. The Taliban, with their interpretation of Islam, believe it to "prohibi[t] the depictions of the human form in photographs, in statues or in paintings." Apparently they haven't read The Quran carefully enough.

Praise be to Allah

Indeed. Glory be To HIM.

Re:Then what's the point?

[SuperKendall]

What I'm sayinmg is that people wont be making new interfaces in SOAP all the time, instead they'll just grow/prune the interfaces.

In other words, I am a believer in SOAP, but only when used correctly! Like all tools, it has it's place.

Re:SOAP's real technical benefits

[TWR]

Traditional RPC protocols also require you to statically bind to an interface (.h file, .java file, IDL file). This means that when an interface changes, you need to recompile. This sucks.

And if you change your parameters for your remote procedure call, what magic part of SOAP is going to re-write your code to make it understand the changed protocol? Repeat after me: "Strong typing is a GOOD thing."

SOAP is dumb. It is solving the same problem that CORBA does, only it does it using a more verbose protocol. Wait a sec; Microsoft is behind SOAP. Now this makes more sense. They're just bringing bloat to RPC calls ;-)

-jon

Microsoft is irrelevant

[mnf999]

At least in the J2EE copycat that .NET is.

It is standard tactics for microsoft lovers to say "oh microsoft is SOOOOO bad, SOOOOOOO Bad BAD BAD!!!!!" because, don't you get it? it makes you think about them. I am serious now... mind games...

Ok onto SOAP. Follow the BOSS (http://www.jboss.org) and check out what the J2EE folks are doing with SOAP. JAVA LOVES SOAP. and we also know a little truth that .net folks forget... that Client Server is dead so that Corba/Soap/RMI are dead protocols anyway...

Microsoft is playing a "meetoo" and using usual tactics of "look how bad bad bad we are" so that you are afraid and go with them (he he). But frankly with 90% of the app server market in J2EE WHO CARES???????

So the browser is IE?? WHO CARES???? I was using netscape, went to IE cause I got tired, and tried Gecko netscape 6 yesterday, it's quite ok.. but REALLY WHO CARES?????????????????

THE REAL BATTLE IS ON THE SERVER and there Microsoft is misfiring with windows 2000. Yes, sure they ship it as much as they can but DON'T YOU SEE LINUX IS A FORMIDABLE CONTENDER AT THE LOW END, and it will be a cold day in hell before win2k replaces SOLARIS at the high end. DON'T YOU SEE???? THEY DON"T HAVE A STANDARD, IN FACT THEY ****BARELY**** HAVE A SAY IN WHAT TECHNOLOGY SHAPES THE SERVER WEB (PHP/J2EE). So f*ck them, that article was stupid, tried and true tactics from a self-loathing pro-MS "pseudo" technologist.

Did you get the reference to "Open Source Programmers have embraced it" SURE WE DO BIOTCH! we got it in JBoss.org and we think it is a good little kinky technology for CS calls. Do I think it is the future? no biotch, no! WE ARE THE FUTURE.

So check us out http://www.jboss.org

marc

Re:Microsoft is irrelevant

[arturo_1]

Sorry about my english (I am spanish parlant) I agree 100% you that the real battle is on the server side and Microsoft need time (.NET) to do something? (I believe they don't know what) because windows 2000 is flawed. Distributed process and language interoperability are to be trashed in a few years, so I view in the future terminals (or ultra-thin-client at the client side) driven by servers (as has being done in the 'dinosaur era'), an enhanced TCP/IP, a message system-protocol as simple and efficient as possible (none of actual mess) to hold terminal to host and host to host interaction.

Re:Microsoft lost control of SOAP :)

[SoftwareJanitor]

Well, well, an admission of being a Microsoft paid troll. Very amusing. Well, I'm unimpressed by your self righteous attitude. You really don't know who I am or what I know or don't know so what room do you have to complain about silly guesses? Taking a couple of what I admit were rather snide remarks about Microsoft not playing nicely with others to "making things up" seems like a bit of a defensive stretch. Obviously huge multinational companies like Microsoft and IBM may work together on some things, and be bitter adversaries in others, but my comment stems from the fact that Microsoft doesn't seem to know how to be loyal to their allies in the long term. The old IBM wasn't much better, but from what I've seen of the new IBM, they have cleaned up their act. At any rate, for someone who lacks interest, I must have struck a nerve for you to bother to reply more than once. I was also curious as to whether Sheldon was replying anonymously to support his position astro-turfily, and you've more or less answered that as well if what you say about not having registered for Slashdot is true.

Re:Binary Data?

[baka_boy]

MIME attachments to SOAP messages are acutally entirely 'standard' (or at least as standard as any non-W3C XML-related spec gets). There's a W3C Note describing a standard means of handling multipart MIME messages with the SOAP framework; that would allow you to 'attach' the raw binary data to your message, and simply reference it from the SOAP envelope via a relative URI.

Of course, you're still not going to have absolute efficiency, since along with XML's verbosity, you have the additional overhead of the full SOAP envelope and mutipart MIME formatting to deal with. If single messages contain large BLOBs, though, that's going to be water under the bridge.

Re:SOAP's real technical benefits

[q000921]

Traditional RPC protocols require one to know that a method is of the form:

foobar(int a, int b, char[] c)

With XML, each parameter is defined by a "tag". This allows position independence -- one only has to state the name of the parameter that the piece of data is for. (Insert analogy to Smalltalk method parameters here.)

SOAP is kind of ambiguous on the issue of positional or named parameters.

If you want to bind existing code to RPC interfaces, you must support positional parameters and you must ignore parameter names because most existing languages use positional parameters. An RPC binding for Java or C that uses parameter names is simply incorrect because it doesn't reflect language semantics.

"void f(int x)" and "void f(int y)" are the same interfaces in C/C++/Java. If you haphazardly used named parameters, you'd be missing a parameter. Or, if you declare a function as "int f(int x,int y)" in one place and "int f(int y,int x)" in another, you'd be calling the function with the wrong arguments if you used named parameters. The only way you can introduce named parameters for C/C++/Java interfaces is if you add new mechanisms for declaring how named parameters map onto the positional parameters of those languages. In different words, if you adopt a named parameter scheme, you cannot build an automatic mapping from C/C++/Java interfaces onto SOAP interfaces (unless you call your "named parameters" something like "arg0", "arg1", ...).

Note that Smalltalk parameters are, in fact, positional: "x put: y at: z" is not the same as "x at: z put: y"; in the first case, the method is "put:at:", in the second case, the method is "at:put:".

Traditional RPC protocols also require you to statically bind to an interface (.h file, .java file, IDL file). This means that when an interface changes, you need to recompile. This sucks.

Yup, dynamic interfaces are nice. Of course, lots of systems had them before CORBA and DCOM side-tracked the industry.

XML RPC frees you from having to use a standard object model, or a standard language. You can implement an XML RPC endpoint in ANYTHING you want -- there's no model to bind to. Every call is dynamic.

First of all, XML RPC is not the same as SOAP. In any case, not specifying the object model is not the same as not having one. In fact, SOAP has an object model, it just doesn't specify it. And SOAP's object model maps quite poorly on the object models of existing languages. That isn't freedom, it is merely forcing you to put in a lot of effort in exposing your interfaces in ways SOAP can actually handle them.

[SOAP] defines a standard type encoding (for arrays, structs, etc)

It doesn't really. The current SOAP spec doesn't tell you unambiguously how to represent common datatypes like arrays, strings, or structures. It gives you types that kind of are roughly analogous, but that's all. If these types interoperate between different implementations, it's because of conventions that are outside the SOAP spec, not because SOAP defines a standard.

SOAP is actually pretty typical of vendor standards: it specifies enough to give people a warm and fuzzy feeling, but it isn't sufficient for people to write truly interoperable implementations. That's great for the people who set the standard, it's useless for the industry.

HTTP provides the final value-add in that it's ubquitious, firewall-friendly, and clear-text.

It's too bad that SOAP doesn't commit to HTTP as a transport protocol. Because it doesn't, you can't really rely on HTTP mechanisms when implementing SOAP or defining SOAP-based functionality.

too simple

[GCP]

xml-rpc requires that all strings be 7-bit ASCII. Pretty dumb. Few languages can get by with such a pitiful character repertoire.

Um...

[Fervent]

I read the whole article, and I have only one question.

What is SOAP? They don't seem to explain it at all.

Re:Um...

[mapMonkey]

I stand corrected:

from Miscro$oft (re SOAP 1.0):
"SOAP doesn't care what operating system, programming language, or object model is being used on either the server side or the client side: it is utterly agnostic, except that it needs HTTP as a transport." ( emphasis is mine )

and from W3C( re SOAP 1.1):
"SOAP can potentially be used in combination with a variety of other protocols"

Re:Um...

[sporktoast]

I was pretty startled that someone with mod privs was old enough to get the reference and rate that post as "funny".

Just when all the 31337 kidz around here were making me feel old, slashdot surprises me again.

Or perhaps I just have cable and syndication to thank...

Re:Um...

[BitchAss]

The truth is that SUN had it right from the start. They kept spouting all that "the network is the computer" stuff but now we see that it is the truth. And ironically enough that is exactly what Microsoft is saying when they talk about the .NET "platform". I was at a Microsoft training session yesterday on VisualStudio .net and I actually found it very interesting. They talked about a bunch of different things that .net change and how it would affect us: the developer. They talked about XML/XSLT, SOAP, WSDL, DISCO, Visual C++, C# (which really looks like a cool language), Visual BASIC and how this will change those people who choose to develop under microsoft. I was actually very impressed with the amount of work Microsoft has put into this release. While this might seem revolutionary and more than enough for now, it will not be enough in the future. What we really need is somthing which supports the full OO architecture. But .net does support full OO achitechture. Web services allow for objects to be exectuted over the web. This is a more elegent way to call remote methods since they happen over a web port instead of an RPC port. If you're talking about client side objects then you should see how .net has improved client side javascript. Everything is an object in .net, javascript included. Let's not waste anymore time with SOAP and legacy technologies and give our full opensource attention to the real future, java and jini. SOAP is a legacy technology? It's closed source? Did you read the article? Do you know anything about it?

Re:Um...

[sporktoast]

Besides, just saying something you recognize with the word "Soap" in it, just because it's an article about "SOAP", is not +1 Funny, it's -1 Off Topic.

I'll have to concur with the other AC reply to your post. You have far too limited a sense of humor.

Sure that might have been something of an in-joke, but the comment was also funny in the way the tag line from the sit-com *fit* in the context of the comment to which the poster replied. See, the person was confused about what exactly SOAP is. And the quote... Ah, forget it! Explaining a joke is the quickest way to kill what's funny about it.

I suppose you also despise the little from the better-then-dove! dept. subtitles in every /. article.

Really, ALL humor is culture-reference. Try telling a blonde-joke, or a priest-rabbi-minister-walk-into-a-bar-joke to a native Samoan and see how funny he thinks it is.

Re:Um...

[BitchAss]

Let's not waste anymore time with SOAP and legacy technologies and give our full opensource attention to the real future, java and jini.

I forgot to include this link. The link is to an open source OS that is built on the .net infastructure. It's written mostly in C and C#.

Re:Um...

[KnightStalker]

> It's written mostly in C and C#.
> CVS Repository ( 0 commits, 0 adds )

ITYM "will" be written, especially since C# requires a runtime that doesn't (yet?) exist for anything but Windows :-)

Re:Um...

[BitchAss]

ITYM "will" be written, especially since C# requires a runtime that doesn't (yet?) exist for anything but Windows :-)
You're quite right - my mistake :)

The presenter at the conference also mentioned that the .net runtime would be made available for someone to develop for other OSs like Linux, Solaris or Mac. I wish I had a link to this. Does anyone have anything that says something like this?

Re:Um...

[zzzeek]

it is a protocol for invoking methods via XML whose development is being led by Microsoft. Its many enthusiastic headlines on Slashdot leave me quite suspicious of slashdot's editors either being extremely naive or extremely devious (under the directorship of VA Linux and their vanishing business model).

Re:Um...

[IntlHarvester]

.NET is revolutionary for VisualBasic programmers, because it essentially puts them in the same territory as Java programmers. The cost of this, however, is that a huge chunk of their VB6 stuff breaks - the cost of turning VB into a 'safe' language.

On the other hand, if someone has already invested in Java, .NET really doesn't give you anything except a 1.0 RSN platform. The features it does have (including SOAP and 'web objects') could be added to Java (and probably will be) by the time MS ships.

My feeling is that C# is really there for propaganda value, both so that .NET doesn't get pigeonholed as a "VisualBasic" technology, and so that MS can tout it's language-independance. Plus it gives them the JUMP Java migration program.

VB has lots of users behind it, and MS is planning to ride .NET in on VB programmers. Too bad Sun didn't come up with the idea of a ObjectBASIC for the Java Platform a couple years ago.
--

Re:Um...

[sheldon]

I see the crazies are out in full force today...

Re:Um...

[linzeal]

SOAP is a lightweight protocol for exchange of information in a decentralized, distributed environment. It is an XML based protocol that consists of three parts: an envelope that defines a framework for describing what is in a message and how to process it, a set of encoding rules for expressing instances of application-defined datatypes, and a convention for representing remote procedure calls and responses. SOAP can potentially be used in combination with a variety of other protocols; however, the only bindings defined in this document describe how to use SOAP in combination with HTTP and HTTP Extension Framework

from http://www.w3.org/TR/SOAP/

Re:Um...

[radish]

SOAP == Simple Object Access Protocol.

A protocol which allows remote object interaction (c.f. DCOM, RMI) by using standard format XML messages passed over HTTP. SOAP is essentially an open standard but it is being heavily promoted by M$ within their .NET framework, Sun have blown hot and cold over it for the last 6 months or so. Currently they say it's a good thing.

Check here for more info.

Re:Um...

[Winged Cat]

And that's why they do it: so you can't just firewall out their insecure "advanced" features. They have no reason to care about your security, except insofar as it makes you more likely to purchase their stuff (not an issue if their management sincerely believes there is little significant competition), but they do have incentive to make sure their software running on your hardware runs all the connectivity features they say their software does.

Re:Um...

[Lord Omlette]

they build their proprietary Windows only networking system just to have someone Samba their way in with Linux? Relax, it's just engineers doing what they do best: making something fit where it shouldn't and previously wouldn't.
--
Peace,
Lord Omlette
ICQ# 77863057

Re:Um...

[Sloppy]

Confused? You won't be ... after this week's episode of SOAP.

---

Re:Um...

[mapMonkey]

... standard format XML messages passed over HTTP

Actually, the SOAP spec does not specify which protocol you need to use to pass the messages. HTTP will obviously be a very common choice, but it's OK to use other protocols.

Re:Um...

[mbyte]

Am I the only one who thinks this is kinda stupid ?

I mean, they are basicly doing tunneling corba/RMI/etc. calls over HTTP .. for what reason ? right ! to go behind firewalls ! So .. I build my firewall, allow only HTTP, then they start using it as a tunnel device !!?

Re:Um...

[SoftwareJanitor]

Sun have blown hot and cold over it for the last 6 months or so.

Well, SOAP started out as an extension to XML-RPC. Sun liked XML-RPC. Sun didn't like the initial version of Microsoft's extensions to XML-RPC because they thought they favored Microsoft (surprise surprise). IBM didn't like the initial version of the SOAP spec either, and proposed some changes, which became SOAP 1.1. Sun likes IBM's revised spec (both Sun and IBM are Java proponents, amongst other things). So Sun really hasn't been terribly inconsistant about things. Also, many people have taken Sun's involvement with other, sometimes similar technologies (like Jini, CORBA, etc) as well as them not dropping RMI as being cold towards SOAP. However, I think Sun is just hedging their bets and trying to embrace as many things as makes sense for them to do.

Currently they say it's a good thing

Like I said, the SOAP spec changed, unless the spec changes again or something else comes along, I wouldn't expect Sun to change their position again.

Re:SOAP's real technical benefits

[Malcontent]

Once people can invoke COM objects over HTTP all hell is going to break loose on the corporate world. I pity the poor corporate IS shmuck who has to add yet another task on to this overworked plate. Between trying to please clueless PHBs, operators from hell, programming and such. It will take years to get the security infrastructure in place when any idiot can call com objects over the net. Of course by then SOAP will be left in the dust as MS pushes their new acronym of the day.

Re:Then what's the point?

[sheldon]

But that's what I'm saying. You create a new interface, leave the old one behind unchanged so you don't break existing clients.

Like I said, I don't understand why you wish to start an argument with me by agreeing with me.

Re:Then what's the point?

[Malcontent]

I agree. If you have to rewrite your code anyways why depend on a verbose bloated thing like XML.

You can pass perl type hashes just as easily for example and save the parsing overhead and the extra tags that bloat the packet.

New "nice" scanners, viruses and trojans...

[patrixx]

SOAP is HTTP carried XML. It goes straight trough any firewall like an HTML page, and if there's a SOAP enabled webserver at the other end the server will try to forward the SOAP call to an object. This could be a new frointier for virus makers and crackers.

For example write a scanner that via SOAP calls COM objects on random IP adresses and asks them to declare their interface. If you find an object that seems interesting. Write a program that calls that object and tells it to do something nasty...

Sure you can implement handshaking and such when using SOAP, but developers are not the most security minded people. Thats why we need firewalls in the first place.

Does SOAP have the potential to shoot firewalls back to square one, because HTTP is now a protocol that not only delviers HTML?

They won't do it right.

[befletch]

I don't mean to Microsoft bash, but...

We already know that they don't know how to
set up DNS. (ie primary/secondary DNS on the
same box until about a month ago)

They also don't seem to be able to configure
a web server. Try:

telnet www.microsoft.com 80
(Connecting, etc...)
GET / HTTP/1.0

You get something like:

No site configured at this address

Seriously. Try it. Variations like 'GET /' or
'GET / HTTP/1.1' are equally entertaining.

If they can't make these basic sort of web
standards go, what are the odds they can
create one of their own and get it right?

I am interested in XML-RPC, though. Dave can
do 'simple but effective'.

Re:They won't do it right.

[swb]

For the midmarket they don't have to get standards right, they only have to have a certain amount of internal consistency with their own products. Lack of or weak interoperability has been their chief means of extiniguishing others that try to compete with them. This also spawns a fawning aftermarket of developers that come out with products that attempt to work around MS interoperability problems.

Re:They won't do it right.

[RedGuard]

You're probably behind a transparent proxy which
requires a hostname.

Why SOPA is so important

[garoush]

Put simply, using SOAP, two or more 'alien-things' can communicate to each other as long as they agree on the SOAP protocol - which is the ONLY requirement when doing client/server using SOAP.

Sure CORBA, DCOM, COM+, Java, etc. allow you to enable two different components to talk to each other, but those technologies do it in such a way that you must have a 'piece' of the server (called the client) to be delivered and used by the client developer. Thus, to talk with a 'server' you must meet the needs of the 'server' when using CORBA, DCOM, COM+, Java, etc.

With SOAP, this is all eliminated. As long as the server publishes its API via the SOAP protocol, I can write my client to talk with the server using what ever I want. This frees me from having to 'embed' in my client a piece of the server -- thus there is no longer any 'hard-coupling' between two 'things'.

In short, using SOAP, we now enable a true 'smart' data-exchange-protocol between two systems such that development is now at the level of "data-exchange" rather than API, SDK, language, etc.


---------------
Sig
abbr.

Re:Why SOPA is so important

[david_goldstein]

This might be easier to understand than CORBA, and lead to more people "getting" it and using it. That is its only real strength...but that, along with industry backing, might be enough.

Isn't that the point of interoperability standards. Critical mass is the important thing. Everything previously was too complicated to get critical mass. Maybe SOAP is too complex and XML-RPC will be the winner. But at least we get to stop trying to make IIOP and DCOM and RMI (and other FAT ASS protocols) try to get critical mass

Re:Why SOPA is so important

[listen]

I don't get this...

To implement a CORBA client, your client and server must both implement enough of the CORBA spec to talk to each other. Now it can all be done dynamically, ie look up the interface in the interface repository and use DII to call things. Or it can be done with stubs.
None of the server is embedded. It is
*possible* to generate stubs from the
*interface definition*.

To implement a SOAP client, our client and server must both implement enough of the SOAP spec to talk to each other. Now it can all be done dynaically, by downloading the xml defining the interface. Currently I know of no work on stubs, though I'm sure it must be possible.

So all SOAP does is have a less efficient
encoding( may be alleviated by some kind of
compression), and emphasises the transport layer rather than the interface definition.
It isn't a magic thing, it doesn't write programs for you.

So what does this mean? It means you have to write a lot of XML with your program. This might be easier to understand than CORBA, and lead to more people "getting" it and using it. That is its only real strength...but that, along with industry backing, might be enough.

Ugh...

[DrEldarion]

I wish some of my coworkers around here would take advantage of the opportunity of SOAP.

-- Dr. Eldarion --

Re:Microsoft lost control of SOAP :)

[sheldon]

I could care less. It was the work of creating the SOAP spec 1.1 that Software Janitor was whining about.

Re:Binary Data?

[alienmole]

Thanks for the clarification. I knew that MIME attachments were supported by SOAP, but I wasn't sure of whether pure binary attachments - as opposed to encoded attachments like Base64 - were allowed, whether by SOAP or even HTTP. I haven't seen them used very often so I wondered if there was a reason for that.

Re:Hall o' mirrors

[realkiwi]

News flash:

Dave Winer's ego has exploded. The explosion took down two high rise buildings causing unestimated loss of life.

The good news is that the last living person without a sense of humour (DW) has finally passed on...

VS.NET development

[norikosakai]

I agree that developing with .NET sounds great for VB programmers (myself having been one of them - notice here the past tense) because of the CLR. My concern is that the lure of the CLR and the speed of development using VS.NET may come with a price. If your main objective is to develop web services and quickly deploy Microsoft injected apps, then great. If you are using VS.NET because you want to put your current programming language on steroids (whether it be VB or other) then like myself... I'm a little wary. Aside from having to maintain and debug code that has been segmented with a variety of syntax (because hey... you know as well as I do that it's not easy to go through someone else's work), there are some other important issues to consider. Performance... there really is a hit here because Microsoft is trying to automate memory management in VS.NET to make it easier for apps to be pumped out with success. Did people request this?? I wasn't one of them. Microsoft specific... are the fruits of my efforts going to be enslaved by what Microsoft does? Will Microsoft realize the impact their changes have on the general population of developers? While software development is driven by the market to become platform independent (and believe me, this is the case)... does VS.NET move me in the right direction? I've got quite a few more... but these are the two that concern me the most. I've seen the beta 1, and I think it's great... but not without my concerns.

Re:Yet he forgot...

[Malcontent]

"But don't let me stand in the way of gratuitous microsoft bashing or anything."

There is nothing wrong with MS bashing. MS is not above critism it's just a fucking corporation not a god. You are lucky he did not do one of the following..

Call them Un-american.
Bribe I mean lobby politicians to make laws that would make coding windows illegal.
pay people to disrupt public forums.
pay people to say bad thing about them and good things about himself.
Lie under oath
Engage in evidence and witness tampering in a federal court.

The undisputable fact is that MS is one of the most unethical companies on the planet and should be bashed and critisized daily till they behave like responsible citizens.

Why should they be held to a different standard then Nike, Exxon, Firestone etc.

This shit ain't gonna work!!!

[Galactic-Geek2000]

This SOAP stuff sounds good in theory, but I am sure that it is not going to work in practice. At least not for several years, after tens-of-thousands of programmers have wasted their youth trying to figure out why something doesn't work. Service packs upon service packs. Hot fixes upon hot fixes. Reboots upon reboots. Incompatible versions of MDAC, ADO, DAC, MTS, and on and on. This is going to be one horror story. I shudder in pain.

Of course, I won't be experiencing any of this pain, since I will be happily coding PHP. Just a hunble little scripting language, that PHP, but makes you money. Ha, ha, ha!!

I make money while morons rot in vaporware hell....

Galactic Geek

SOAP -- issues re:HTTP, RPC, and Firewalls

[Sweetums]

We have watched SOAP reasonably closely for a variety of reasons where I work, and there are a couple of things that others here have touched on which I also wanted to comment on.

HTTP -- one of the other folks higher up noted that SOAP uses HTTP for transport, but is not tightly linked. I was not aware of this, but that was one of my primary concerns, trying to overload this functionality on a prototcol which was designed for other things.

One of the things cited initially as a benefit of SOAP was that it does use HTTP and therefore can easily pass firewalls without lots of extra configuration and support worries. On the one hand this is good for ease of support, on the other hand, it gives somewhat less control on the Firewall as noted by another post. In the end one could write validation routines for SOAP via HTTP as easily as one could for standard HTTP. It's the same problem one has detecting netcat connections masqerading as HTTP.... not a lot of good solutions out there in use yet.

RPC -- is what it is. There has been a fair bit of discussion as regards SOAP and some of it's percieved competitors. In the end a big piece of SOAP is the RPC stuff transported in an XML framework. If you need to do RPC that is cool, but RPC is not panacea. When you need it you need it. When you don't, it's likely to cause you more heartache than joy. As I understand it, it is difficult to do right, though I have never been involved in an implementation myself.

------------------------

Re:Hannibal

[Alien54]

I hate the New York Yankees because they try, and succeed, in beating other baseball teams -- like my favorite team. I have heard their players say with glee, "We are going to kill the competition". They will trade and recruit players to better their team while hurting all the other teams.

if the NY Yankees not only competed in the game of baseball, but also acted so that they would always win the world series because they were literally the only team around, having bought out all the others, leveled the stadiums, then you would have an argument.

But The Yankess do not have a monopoly on baseball. If the Yankees had a monopoly on baseball, and wanted to extend it to football, or into other sports, then the analogy would fit. They don't, and it doesn't.

Your logic is fundamentally flawed due to the inappropriateness of the example.

But MS does have a monopoly on the OS market.

Re:Why SOAP is so important

[garoush]

I think you are missing my point and the big picture of SOAP/XML.

Lets say I came up with a new device imbedded in my watch and this device wants a simple service from a server (lets say the weather for NY city or any other city from my limited selections). Lets say there is a server that provides such a service but this server provides an SDK/API based client based on CORBA, Java, etc. So if my limited device wants to get the service out of the server, it must implement the server's SDK/API requirement.

While this is not a problem in a fully fledge environment, it is a serious limitation for my device. The only way I can address it is create my own server, which acts as a gateway between the real server an my device. A doable solution but unnecessary.

If you think about the problem that I presented and you extend it to other 'services' you will see that SOAP (and XML) is the answer. Lets face, it EDI (if you don't known what that is and it's importance within Fortune 100 companies than you will never understand SOAP or XML) is what used today as the primarily means of exchanging 'smart' data between two or more trading partners that include banks. EDI has a lot of limitations, XML and SOAP will fix all this.

Finally, you say SOAP is a M$ implementation. This is not 100% true, if you studied XML and SOAP, you will see that SOAP was XML-RPC. Microsoft did try to tie SOAP to its implementation but it gave up.


---------------
Sig
abbr.

Never heard of virtual hosts ?

[javaDragon]

$ telnet www.microsoft.com 80
Trying 207.46.131.199...
Connected to www.microsoft.akadns.net.
Escape character is '^]'.
GET / HTTP/1.0
Host: www.microsoft.com

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Content-Location: http://www.microsoft.com/Default.htm
Date: Sat, 03 Mar 2001 00:44:24 GMT
Content-Type: text/html
Accept-Ranges: bytes
Last-Modified: Mon, 26 Feb 2001 14:08:27 GMT
ETag: "be3b597fd9fc01:858"
Content-Length: 18095

(etc, etc...)

LOL!!

[the coose]

Thanks for quick trip down memory lane. :-)

MS? ughh

[Alien54]

In the recent comments on the Microsoft trial , I came to the conclusion that Microsoft is the corporate equivalent of Hannibal Lecter. In my opinion.

Now I've calmed down abit since then, but I must say that there is a certain truth to it as far as their behavior in the market place. In my opinion. In any case, they display the behaviors that are very similar to a serial killer. In my opinion. This of course, does not make what they do illegal. I am sure they only have the good of mankind in mind, as far as they understand it.

The question I see here in this context is if Microsoft can be trusted, given their corporate culture, etc to do the right thing with SOAP. or will they somehow continue to try to make it an exclusive MS thing in the process, even if it breaks it?

Let's face it, a Microsoft *only* Internet is a broken Internet. In my opinion.

And besides, how much would you trust having someone like Hannibal Lecter in your life?

SOAP

[garoush]

If you look deep into SOAP you will see that it is about solving everyday business problems.

Sure it is based on XML markup; sure using CORBA, DCOM, etc. you can enable two object to talk to each other; and so fort. SOAP solves this communication/service problem buy promoting a business-logic instead of a technical-tool.
---------------
Sig
abbr.

Re:SOAP

[SuiteSisterMary]

Don't forget to wear the feathered Can Can outfit when you go to see the hot lawyer; turns out she's a cross dresser.

Open Source has also discovered SOAP

[Sam Ruby]

Of course Dave points out that open source has noticed XML RPC (his baby), but the open source community has also discovered SOAP: http://xml.apache.org/soap/.

Re:SOAP is only one part of Microsoft's .NET strat

[hypermatt99]

You make no sense the common language runtime is for writing .net executables like java has its own runtime. SOAP is just a transport layer for abstract functions that can be on any system. Infact the soap standard is maintained by the w3c. Anyone could write a soap client or server for any operating system there is nothing microsoft specific to SOAP.

Re:europeans

[chucking]

Someone shot the food

Re:Hannibal

[gsarwar]

Your post just shows that Micro$ofties don't get it... do they? Its one thing to compete on merits and its other to kill the competition based on your monoply in existing infrastructure. What do you say about M$'s threats to OEMs to just release IE with windows? To threaten them to not give Netscape as an alternative option? What do you say about M$ making agreement with AOL to provide IE with their software and not Netscape? If you're interested to know more, go visit this site: http://www.vcnet.com/bms/departments/dirtytricks.s html

Hannibal

[AdmrlNxn]

Microsoft the equivilant to a serial killer? I hardly see a similarity.

You are compairing a murderer who has no shame for his crimes in brutally slaughtering his victims and a business who provides just competition. Microsoft doesn't committ any acts of violence and indescretion in the computer industry. Competeing companies just can't keep up with the giant.

Look at Netscape.

It was a great idea and Microsoft thought... fuck that is a great idea lets make one of our own. (Now all businesses are about money, don't forget that) So they realized they had competition so they...

A. Made a better browser
and B. Starved the competition

What they did wasn't illegal or wrongful or unjust. Linux distros do it all the time. They tie in with the OS a series of applications. Some distros have 1500 apps, some have 3000 apps. They are all in competition with each other because they all sell their version with a price tag. (Plus an option to download) You can't say they aren't in competition becasue they are. They need to pay the bills some how and it isn't through tech support. They are where they are to make money. Period.

Microsoft just made an app that ran and tied it in to Windows 95. Later thinking... oh shit what if we made it apart of the OS, that would be way fucking cool. And in doing so, didn't force you to use the browser, but it sure loaded a hell of a lot faster that Navigator. Because it was already cached and waiting.

Netscape just fucked up! They failed to make a superior product. If they had made a superior browser then we would all be using and paying for it right now wouldn't we? Hmmmm? I think so due to its popularity back in the day. I know it was all I used until realizing 4.X sucked ass against IE5X. Everything just seemd so fast in IE.

Now I know you are a feverous Microsoft hater. But try to show a little respect for a company that is safe to say one of the best things that has ever happened to the computer industry. I mean think about it...

What if Microsoft never existed. No DOS, no Win95, no IE5, nothing. Where would we be? ONe of two places... OS/2 or Macintosh. (Mor likely Macintosh) Linux would still be nearly where it is today. Because the computer industry isn't defined by the techies and IT's... it is defined by the computer semi-illiterate-I-wanna-check-my-email-and-chat.

This is true.

Besides I can only think of two companies that would have made the internet as promising as it is today. Ironically enough they are the ones who did. Microsoft and Apple. When I think of internet, as well as anyone of my computer illiterate friends. We don't think of Linux... the first name that comes to mind is Microsoft. Because they pushed it realizing its potential. They may have not been first to jump on the band wagon... but they sure made the band wagon popular.

That doesn't sound like a sadist killer now does it?

All Linux fans have the same jibberish that spills from their mouths. A conglomerated mess of bad information, fantasy, stupid opinions and Mountain Dew. It is just blah because the only ones who really listen and think you make a point are your own kind.

P.S. Oh, I am sure Microsoft only internet won't ever happen. The internet isn't defined by Microsoft, it is just made more asthetically pleasing by Microsoft.

~AdmrlNxn
Whistler is to Zeus as Linux is to Hercules

Re:Hannibal

[Alien54]

Of Course, I expect Microsofties to be outraged by this.

But is it just the picture of Companies that offer interesting technologies, or possible future competition to MS being bought out, with the technology dis-appearing (consumed, if you will) or otherwise killed off.

It is one thing to compete in the market place to make sure your product does well. It is another thing to want to kill off the competition.

Thus we get to the analogy of murder in the corporate sphere, where one company plans to kill off and destroy another; and deliberately plans to loot and otherwise consume the resources of the other.

The record of MS in this regard is less than stellar, in my opinion. Yes, there have been other companies that are also not so pure. and there certainly is no law against it.

But this does not stop me from stating my opinion regarding the aptness of the similarity in my eyes. This is in fact, in my opinion, Hannibal Like Behavior. We should discourage it. But how do we discourage hannibal from his ways?

This opens up a whole new view on corporate behavior, where virtual persons like corporations have the same responsibilities regarding other real and virtual persons, and are held to the same standards of behavior that ordinary citizens of the world are expected to maintain regarding themselves and others.

of course, the reaction on the other side of the fence is going to be panic, outrage, and smack this down NOW! Because to do otherwise requires recognizing some of the possible truth in the analogy in the first place.

Re:Hannibal

[demon]

Just thought you should know that Microsoft didn't create IE on their own - they screwed over Spyglass to get it (by licensing it from them, then later distributing it for free - then not paying all the licensing fees).

I know you like Microsoft and all, but don't revise how IE really came to be. Microsoft cheated their way into possession of the code for what became IE, and the more people that understand that, the better, IMO.
_____

Re:Hannibal

[Alien54]

well, just physically count the total number of computers out there. Granted the servers from sun, etc. - but do these run into the tens of millions? hardly. While you have many other niche companies, even a large company like Apple only holds 5% of the volume market. and Linux is far behind. Servers are a niche market. The physical numbers speak for themselves.\, pr and hopes aside.

And let's face it, many companies are terrified of MS even hinting at coming into a market. It is enough to shatter any hope of venture capital. They are in mortal fear. The best many people can do, once that happens, is pick over the bones.

SOAP's real technical benefits

[Stu Charlton]

Taking away the hype, here's a simple look at: "Why SOAP for RPC?"

1. The real value comes from XML.

   XML as a data representation has 2 major differences between it and the other more popular RPC protocols:

   1. It ships semantics with the data (i.e. it's a semantic data stream)
   2. It does not require static interface for 2 endpoints to communicate.
   Let me elaborate:
   • Traditional RPC protocols require one to know that a method is of the form:

     foobar(int a, int b, char[] c)

     I.e., you need to know the positions of the parameters, and their types.

     With XML, each parameter is defined by a "tag". This allows position independence -- one only has to state the name of the parameter that the piece of data is for. (Insert analogy to Smalltalk method parameters here.)

   • Traditional RPC protocols also require you to statically bind to an interface (.h file, .java file, IDL file). This means that when an interface changes, you need to recompile. This sucks.

     With XML, the interface for an RPC is defined by an XML Schema Definition, which is just a type/structural description of an XML document. No binding. No recompiling. No registry hell due to immutable COM interfaces.

   • Traditional RPC's were "static first, dynamic second". One could call COM components dynamically through Automation -- but this was an afterthought, and was crufty. Similarily, CORBA had the DII -- but it too was way of "tacking on" dynamic method invocations on top of what was a static model.

     XML RPC frees you from having to use a standard object model, or a standard language. You can implement an XML RPC endpoint in ANYTHING you want -- there's no model to bind to. Every call is dynamic.

2. SOAP's actual value (besides XML) is limited:
   • It's an envelope for an XML document (which can be used as an RPC call) that says "you should know these schemas in order to understand this message".
   • It defines a standard type encoding (for arrays, structs, etc)
   • Can target to specific proxies (actors) application extensions (XML namespaces & schemas)
   • SOAP runtimes will ease development for particular languages. Runtimes already exist for Java, .NET, and other languages.
3. HTTP provides the final value-add in that it's ubquitious, firewall-friendly, and clear-text.
4. Different quality of service needs do exist, so SOAP isn't dependent on HTTP.

Re:SOAP's real technical benefits

[Trepalium]

SOAP and Corba are not opposites. In fact, SOAP can (and probably will) being used as a form of a transport for CORBA. SOAP is more a replacement for the IIOP protocol than for CORBA. In fact, it could work wonders for building bridges between Microsoft's rather proprietary DCOM and CORBA. And to say that SOAP has no benefits over CORBA is just plain wrong. Traditional RPC (DCE, ONC, IIOP and even XML-RPC) requires versioned interfaces if you want to modify or clarify the interfaces, whereas there's a strong possibility (provided the proper tools) that you could have depreciated parameters instead. Versioned interfaces tend to contribute to bloat as the legacy code gets more and more difficult to maintain and keep up to date (look at Windows -- if you think about it, the fact that Windows is even slightly stable is rather amazing given how many backward compatible interfaces exist that were broken by design that must be supported).

And if you change your parameters for your remote procedure call, what magic part of SOAP is going to re-write your code to make it understand the changed protocol? Repeat after me: "Strong typing is a GOOD thing."

Oh, what's that saying... "Strong typing is for those with weak minds." SOAP will likely do the same thing that CORBA or DCOM would do if the arguments didn't match the prototype -- return an error, unless the programmer decided to have it handled in another way. Protecting the programmer from making errors is good to a point, however constantly having the language second guess the programmer isn't.

SOAP is dumb. It is solving the same problem that CORBA does, only it does it using a more verbose protocol. Wait a sec; Microsoft is behind SOAP. Now this makes more sense. They're just bringing bloat to RPC calls ;-)

Lets be honest. It's not like there's going to be tremendous network traffic incurred because of this. SOAP isn't going to replace either DCOM or CORBA -- they're too good at solving the problems they're made for. It'll probably just be used where CORBA or DCOM doesn't work well -- through stupid firewalls that can't understand CORBA or DCOM traffic, for instance. Most firewalls have much more mature support for HTTP and filtering on the contents of HTTP traffic than filtering DCOM (DCE-RPC), CORBA (IIOP), ONC RPC or any other RPC protocol.

The success of SOAP doesn't mean the death of CORBA. As I mentioned above, CORBA could easily operate over SOAP as it's transport, which means you could use IIOP over your LAN where you probably don't have any type of filtering, and SOAP where you might have to go through a braindead firewall.

Re:SOAP's real technical benefits

[sheldon]

You can already invoke COM objects over HTTP. It's been there since MDAC 2.0 as I recall.

It was originally called DCOM tunneling, but was recently renamed to COM Internet Services.

Re:SOAP's real technical benefits

[demosi]

I agree with you up to a point. I think that you've summed up the advantages of SOAP. These are the things that developers are getting excited about. Above all the key to SOAP is it's genuine simplicity. RPC is for the most part a procedural approach to development of distributed systems.
Many subsequent initiatives leveraged RPC technology with late 80s and early to mid 90s thinking of OO Programming practices. These suggest that Object Oriented Interfaces are king, binary on-the-wire protocols are necessary, infrastructure is provided by complicated runtimes and services with the emphasis on static interfaces, requests etc. Dyanmism and Interoperability were aided by programmatically difficult concepts like DII/DSI IN CORBA and Automation in COM. The flexibility was there but it came at a price.
SOAP acts as a kind of Swiss Army Knife / Leatherman toolkit where the developer needs the minimum of infrastructure to get up and running and where interoperability is enhanced by the self describing nature of SOAP.
SOAP would never have been developed in the past as most people would have balked at the idea of the inefficiency of a text based protocol , despite the over-engineered bloat of protocols like OMG's IIOP.
The main problem that I see with SOAP and all XML/http based protocols is that they are being touted by many as firewall friendlyMany admins are worried about requests being sneaked in on PORT 80 leaving it up to server applications to validate them. To them firewall friendly means insecure, unchecked and potentially evil.

Re:SOAP's real technical benefits

[Cardinal Biggles]

3. HTTP provides the final value-add in that it's ubquitious, firewall-friendly, and clear-text. (emphasis added)

Simple firewalls work because different protocols use different port numbers. What we now see starting to happen on the internet is that everybody is starting to tunnel their funky new protocol over port 80 because firewalls usually leave that open.

Now, I don't call that firewall-friendly, but firewall-unfriendly. The people who are trying to maintain a security policy soon will not be able to filter port numbers any more.

Re:SOAP's real technical benefits

[sheldon]

Who says HTTP has to run over port 80?

Re:SOAP's real technical benefits

[goonda]

I think all the hubbub about XML-RPC and SOAP is nice and all.. but as the above poster pointed out, it is a security administrator's nightmare. Unless we as security admins have some way to filter/strip out this info from the HTTP stream, we are going to have a new class of nasty attacks upon us.

Re:SOAP's real technical benefits

[Hard_Code]

I like XML-RPC which is sort of like "SOAP-Light"...it's very simple and to the point.

Re:Why SOAP is so important

[ABIGGUY]

garoush seems to have hit the nail on the head. SOAP is important not because Microsoft is using it, but because everyone can use it. If you're a Microsoft junky and want to communicate your data through .Net, go for it. If not, there's no reason Microsoft should have to be involved in your SOAP implementation.

There are open-source SOAP implementations all over the place. Somebody has already mentioned the xml.apache.org/soap SOAP server, and there's a nice Perl SOAP client at Soap::Lite. A search for "SOAP XML" on Google will provide a plethora of pinatas...I mean matches.

My company is working on a product that will tie SOAP Web Services to back-end databases, legacy systems, wireless devices, and more. The possibilities are endless.

SOAP

[the_tsi]

You have to save your SOAP on a rope until after you work out in the FAT CITY gym. If you don't use soap in the shower, you won't be able to sleep with the Can-Can girl (since you smell), which opens up the whole second chapter of the game.

-Chris
...More Powerful than Otto Preminger...

XML: No silver bullet

[Joseph Vigneau]

I don't completely agree; XML doesn't really ship the semantics with the data any more than any other structured format. The XML is just data; in the end, code determines how that data is used.

Yes, XML makes it easy to allow for positional parameter independance, but if the parameter list for a method changes, such as a name change or an extra required parameter, you will have to modify your code to reflect this. (ie, recompile). To quote you, "This sucks".

SOAP definitely has potential, it just has a different set of features and restrictions than RMI,COM,CORBA,etc.

Re:XML: No silver bullet

[sheldon]

Which is why you don't break interfaces on your components, but rather implement new ones when you need to introduce new parameters or new features.

This will of course be critical with .Net and web services and such, because you don't want to break all your clients or they will call your stuff unreliable.

Re:XML: No silver bullet

[Stu Charlton]

XML does ship semantics better than other structured formats, unless those formats are self-describing.

The whole point is that intead of having a data stream of

1
2
3
4

we have a described data stream:

Foo: 1
Bar: 2
Lee: 3
Loo: 4

That's more semantics than you'll usually get. The code determines how it's used, but we've decoupled the positional-dependence part of those semantics at least.

Now as for interface evolution, XML gives us the opportunity to tack on parameters without breaking the old interface. That's a big win compared to what we had before.

Besides this, everything we've learned from the COM & CORBA days still applies. One still has to apply engineering principles in evolving our XML messages. I.e. we should segregate our Schemas to have a relatively small surface area, we should keep existing tag structures as "immutable", and we should not impact existing tag structures when adding features. We should also make sure our components support multiple schema versions to allow independent evolution.

As you say, it has a different set of features / restrictions from CORBA/RMI/COM. But I think it progresses the interface evolution aspect of things somewhat. And there's always the political aspect of it: i.e. the industry actually is AGREEING about something for once.. maybe.

Hall o' mirrors

[connorbd]

As an old Mac guy, this column gives me the willies.

Let me explain. I have issues with Dave Winer entirely apart from his writing style (best described as stoned out of his keyboard); back in the day he was a Mac developer of considerable influence who became the press's go-to-guy whenever they needed a quote about the imminent death of Apple. The man (in those days at least) felt he had an ax to grind that nobody bothered to bring up; he had major influence in the creation of Apple's scripting architecture and then threw a hissy fit because they didn't do it his way (using Frontier, of course); at least that's how I've heard the story told. Dave spent the next few years whining to anyone who would listen that Apple would go down the tubes for not doing this or that thing that he thought should be done. Saying how nice Microsoft was to him (I remember him saying something in a letter to MacTech about them sending him "bouquets") was part of his spiel. Yessir, that Dave Winer was a popular one in the Mac community.

Now here he is saying how much he hates Microsoft. This probably shouldn't shock me as much as it does, though; Dave has always been one to drift with the prevailing winds. I don't think he's one to be taken terribly seriously (admittedly he makes a number of good points in the article; it's just that coming from him they ring a bit hollow).

/Brian

Re:Hall o' mirrors

[daveuserland]

Your memory is imperfect, I was telling the reporters that the Mac market in the early 90s was bigger than the DOS market of the 80s, that it doesn't have to be as big as Windows to support a thriving developer community. Anyway the cool thing about Microsoft, unlike Apple back in those days that a little pushback wakes them up. That, and helping organize development around SOAP by independent developers was the purpose of the piece. Funny that what we wanted to do for the Mac is now working on the Internet. Have a great day.

Re:Hall o' mirrors

[connorbd]

First off, I was talking about the LATE 90's. Second, occasionally responding to something because it affects their bottom line does not change the pervasive institutional arrogance that is the Microsoft Way (and which you are decrying -- credit where credit is due).

The fact is, you didn't endear yourself to the community you were trying to support because of your approach to the matter, and judging from the reactions you're getting from other /.ers you're not doing much better now. Attitude counts as much as accuracy sometimes (that's why I'm flaming).

/Brian

Re:Hall o' mirrors

[daveuserland]

Let's see, what specific day were you thinking about? ;->

I mostly gave up on Apple in late 1997. My company continues to ship Mac software, but I use Windows now. Once Steve Jobs was back at the helm I knew there was no point being involved with Mac software on a personal level.

Anyway I don't understand the rest of your rant, things are going pretty well now. Like I said in the first post, the things we were trying to do for the Mac are working now, everywhere. I feel somewhat vindicated by that. I gotta go for lunch now, so you get the last word!

Binary Data?

[smcdow]

At the risk of showing my ignorance, (and I haven't looked real hard, either), does XML (and by extenstion SOAP/XML-RPC) have any support for shipping binary data?

Since we're in the remote sensing business, we regularly build systems that ship around a lot (as in GB) of binary data. Obviously, conserving bandwidth in our comms streams is very important.

My take on XML is that it's all text. That's probably a good thing, but converting a single I/Q data point (2 - four-byte floats == 8 bytes) into ASCII (say 12 characters each for I and Q == 24 bytes) for inclusion in an XML message is, to say the least, a waste of bandwidth. Especially, when we need to ship tens of thousands of data points per second over a comm link that may be much slower than even 10-base ethernet.

Otherwise, XML would serve us very well. If there were some way to ship binary data in XML, then SOAP/XML-RPC might prove ideal for our purposes.

If there is a way inclucde binary data in XML, then **please** send me or post a pointer.

Otherwise, we'll probably continue to use straight CORBA.

Re:Binary Data?

[smcdow]

compress your XML doc with zip or the like

Yeah, we considered that, but then we'd be wasting CPU cycles (and time) compressing and uncompressing data.

Guess we'll stick to CORBA. All this nifty IT gunk is useless for our purposes.

Re:Binary Data?

[Decaff]

XML is a pure text system. Binary data has to be converted into a text form (such as Base64). A description of this is at http://support.microsoft.com/support/kb/articles/Q 254/3/88.asp
Also, XML is pretty verbose, so I would suggest that if speed is critical, you avoid it.

Re:Binary Data?

[StrawberryFrog]

> My take on XML is that it's all text.

Yup.

> Obviously, conserving bandwidth in our comms streams is very important.

The XML spec includes a statement that (if my memory serves me OK) "terseness is of minimal importance" Maybe thier problem domain is just different to yours.

If there is a way inclucde binary data in XML, then **please** send me or post a pointer.

compress your XML doc with zip or the like. You should get good compression what with all the redundancies in an XML doc.

Re:Binary Data?

[alienmole]

As others have mentioned, encoding via BASE64 is the common way to do this, but if that's not good enough, another way to handle it in SOAP and XML in general is to reference your binary data from within the XML, as an external resource.

This makes sense when you have rich structured data that can benefit from XML, but also have large binary data - like media files - which are effectively blobs. If all your data needs to be shipped in binary form, then this approach would probably be pointless, except as a way to tunnel through an XML/SOAP-based system.

The resource reference can use any protocol and implementation mechanism you want, limited only by the environment you plan to run in. For example, you could use an IIOP URI to reference the binary data.

You might also package the binary data along with the XML, like a MIME attachment, in which case the URI would reference that. Although possible, AFAIK, this is non-standard and so whether it makes sense depends on what your reasons are for being interested in XML/SOAP, and again, the environment you need to run in.

Re:SOAP on a ROPE

[pod]

I think it's funny that Microsoft called one of their SOAP tools the Remote Object Proxy Engine.

And of course you get just enough of it to hang yourself with...

Ok, ok, nothing to see here, go back to work!

needs to do some research...

[Pfhreakaz0id]

when he says "microsoft talks to SQL databases " and has it's own OO database. I mean, ADO now talks to about anything, not just relational DB's. You can use webDAV/XML or SQL to query it. Or write an OLEDB provider and query it however you want.
---

Re:The overriding conclusing about Dave's rant:

[connorbd]

He used to be a lot worse; back in the day (about 1996) his style was so disjointed that you'd think he was stoned. /Brian

Re:Microsoft lost control of SOAP :)

[sheldon]

That's fascinating, considering Microsoft worked with IBM to implement those changes.

XML doesn't need SOAP.

[tjpalmer]

1.4. With XML, the interface for an RPC is defined by an XML Schema Definition...
2. SOAP's actual value (besides XML) is limited...
3. HTTP provides the final value-add...

So I still don't understand what SOAP is for, and yes I have read/skimmed the spec. I think it provides some great suggestions at how to organize schemas for RPC purposes, but that's all. As for the envelope:

It's an envelope for an XML document (which can be used as an RPC call) that says "you should know these schemas in order to understand this message".

Doesn't XML already have ways to do this (via DTD specifications, processing instructions, and namespaces, some of which are used in SOAP anyway)? As for the destination parts of the envelope and so on, I think the handling protocol, such as HTTP, can do just fine. If envelopes in general are good to have at an XML level, I think it should be made as a specific protocol and not put together with RPC.

I just can't see why SOAP matters. Maybe I'm overlooking something. I haven't actually used it. Is SOAP needless complication or is it useful?

- Tom

Re:Microsoft lost control of SOAP :)

[sheldon]

Microsoft apologist! That always makes me laugh. As if you think it's an insult.

The fact is, I don't have my head stuck up my ass. I see things from a perspective of what actually happens, not some pet conspiracy theory I fabricate in my mind to justify my contempt and hatred.

Oh, sorry... I probably hit too close to home with that statement. :)

Get your head out of your ass and actually look at what is happening around you.

Re:Microsoft lost control of SOAP :)

[sheldon]

Well ain't that just fascinating. Jon Bosak of Sun created SOAP?

Funny, I don't see his name on the credits.

http://www.w3.org/TR/SOAP/

Don Box, DevelopMentor
David Ehnebuske, IBM
Gopal Kakivaya, Microsoft
Andrew Layman, Microsoft
Noah Mendelsohn, Lotus Development Corp.
Henrik Frystyk Nielsen, Microsoft
Satish Thatte, Microsoft
Dave Winer, UserLand Software, Inc.

Wait? Why isn't that interesting. Representatives from IBM and Lotus were involved jointly with Microsoft in delivering this spec.

I rest my case, you don't know what you are talking about.

Re:Microsoft lost control of SOAP :)

[sheldon]

Heh. Well I say it's better to be a paid troll then an idiot who does this for free. :)

Re:Then what's the point?

[sheldon]

I don't understand. Why are you disagreeing and then saying exactly the same thing as I commented?

SOAP is only one part of Microsoft's .NET strategy

[Anonymous Coward]

It is the transport layer. What about the client? To use .NET will require a CLR (Common Language Runtime) on the client. When will we see a CLR for Linux? or a Sun Workstation? or a Mac? or a Palm PDA? or a smart cell phone powered by a non-MS OS? Probably never. What about the server? When will we see SQL Server, Exchange Server, IIS, or BizTalk Server ported to Linux, Solaris, AIX, HP-UX? Never. So once again, we're back to the Windows everywhere strategy. If you want to use .NET, you need Windows on your desktop, your server, your PDA, and your cell phone. No thanks.

Bruce Schneier agrees with you.

[Paul Crowley]

Schneier voiced exactly that opinion in a recent Cryptogram.
--

You really don't have a clue, do you?

[Otis_INF]

C# is a language like any other language. C# is there so people who want to produce COM components with the ease of VB and the speed of C++ can do that with C#. They also could do that with J++ but Sun thought that would be a bad thing (?) so a lawsuit canceled that oppertunity.

.NET's CLR lets all kinds of objects operate and work together (and better: get debugged by 1 single debugger) no matter in which language it's written. If you think this is just about VB you don't get the point behind .NET and why it's so important for every developer out there.

.NET is powered by 20+ languages btw, (including java) so I really don't understand where your FUD is coming from.
--

What planet is he on?

[Decaff]

So the web is no longer a place of innovation?

What about WML, the growth of XML (the basis of SOAP) as a non-proprietary standard, and the appearance and huge success of web scripting languages (such as PHP and JSP).

As for browsers, I use IE, but I also use Netscape, Opera, and Konqueror (the KDE browser). I use Lynx a surprising amount. The non-IE browsers are developing and changing at a fast pace.

And who says WORA (write once, run anywhere) is dead? I develop and deploy cross-platform Java applications. I ship the same binaries for Windows, Linux and Solaris. Anyone else with a Java 1.2 VM can run my stuff - even the graphics. But Java WORA is trivial compared with Smalltalk: if you want to see WORA work everywhere (even on DOS machines) try Squeak Smalltalk.

SOAP is further evidence of the way that the web languages (in this case XML) are experiencing innovation. Unlike COM/DCOM, SOAP allows an escape route from Microsoft-only systems, as its a public and easily implemented protocol.

Who will suppy the Host header ?

[Utopia]

You need to supply the Host: reader buddy.

Try something like this.
GET / HTTP/1.0
Host: www.microsoft.com

or

GET / HTTP/1.1
Host: www.microsoft.com

The error you got was due multiple sites
configured to the same domain name
- pretty normal stuff, most sites do it.

Re:Host is a HTTP 1.1 requirement

[pod]

Which is why IE2 which to this day ships with NT4 CDs can't connect to MS site to upgrade itself. You have to download Netscape first.

Speaking of clear messaging

[xant]

I haven't read a whole lot of Dave, but is he always this unintelligible? Form complete, non-run-on sentences, man! How can he expect us to take his message seriously when he can't even communicate it clearly -- especially when a large part of the message seems to be "Microsoft can bite my ass." The message itself invites scorn if it's not backed up by firm arguments, and presenting it in such a garbled way renders his arguments useless.

To anyone reading this: learn how to communicate, or don't bother to learn how to code.
--

Strong Typing is a Bad Thing

[Stu Charlton]

.. for distributed, coarse-grained, components.

It just doesn't facilitate interface evolution and independent component evolution. The maintainance costs of strongly typed network endpoints do not justify the added benefits.

I think we've spent 15 to 20 years trying to retrofit strong typing on RPC They're all WAY too coupled to an object model or a specific language. It's time to move on to dynamic type checking for network components.

SOAP is marginally useful.

[Stu Charlton]

In reality, SOAP doesn't matter... it's hype. XML messaging in general is what matters.

Regarding its value: DTD Specs are becoming obsolete, and namespaces are more about "scoping" then they are about type-checking or versioning.

SOAP gives you the "mustUnderstand" and "actor" semantics to target specific extensions (schema definitions). It's a marginal benefit.

The type encoding is the other benefit, and it's really just a "first attempt".

If...

[jd]

...we can talk CmdrTaco, et al, to put the article to music, would this make it a SOAP Opera?

I don't see this as a problem.

[Stu Charlton]

I see it as a check, or a balance.

We've been so busy firewalling ourselves from each other that we're not thinking about the ways we can interoperate with each other. Draconian security policies have been a big factor in slowing the progress of the Internet's potential in making business more effective.

If one subscribes to the www.cluetrain.org view that markets are conversations, we need to think of ways to "open things up" while maintaining security. This is a paradox. It's going to be messy.

Which is why HTTP+SOAP is the ultimate messy hack from one perspective, but also a great catalyst for opportunity at the same time.

Re:Yet he forgot...

[Malcontent]

Wow that really undermined arguments. You Mr Coward are just a fucking brilliant!

So tell me are all MS employees as smart and brave as you?

A Couple Of Questions

[Grail]

What dynamically types remote interfaces and service descriptions did "people" have before CORBA?

How does CORBA represent a step backwards?

Re:A Couple Of Questions

[q000921]

What dynamically types remote interfaces and service descriptions did "people" have before CORBA?

Several Lisp and Smalltalk systems implemented dynamically typed remote procedure calls in the 1980's. If you want to count it in, PVM is another example, and there are probably more.

Of course, if we are talking about functionality at the level of SOAP, Lisp had (and has) that essentially built-in: Lisp data structures and function calls can be reliably converted to and from text, and readers and writers are built into implementations. To get SOAP-like functionality in a Lisp system, you need roughly the following:

Complete client code:

(with-output-to-stream (socket) (print '(f 3 4)))
(setq result (with-input-from-stream (socket) (read)))

Complete server code:

(setq result (with-input-from-stream (socket) (eval (read))))
(with-output-to-stream (socket) (print result))

There is no magic going on here: these primitives (under various names) are part of pretty much every Lisp system. A complete Lisp system probably takes less code to implement than an XML library. Lisp is just designed for simplicity and functionality from the ground up.

How does CORBA represent a step backwards?

In my opinion, CORBA is an unnecessarily complex standard. The industry would have been served better by concentrating on a simple, dynamically typed system. If real-world applications had called for additional features, those could have been added later on. And, history seems to be proving that view correct: after 10 years of mucking around with CORBA and DCOM, the industry is now going for XML-based RPC.

Re:A Couple Of Questions

[q000921]

Oops--PVM probably didn't have dynamic features in its first incarnation in 1989, and I don't know when they got added.

However, there is a big literature on distributed computing in Lisp, going back to the early 80's, almost all of which used dynamic typing.

Lightweight? Lightweight?? Lightweight???!!!

[dbrower]

"SOAP is a lightweight protocol" defies all sense.

I can't think of a single use of XML for anything that can be called "lightweight" compared to almost anything else. I even support SOAP for many things, but calling it "lightweight" is a Big Lie technique that doesn't address its real strengths (or failures).

-dB

Host is a HTTP 1.1 requirement

[Anonymous Coward]

It should not be required with HTTP 1.0, as in the example.

Seems like Dave is on some sort of personal jihad

[Anonymous Coward]

the article reads like a mishmash of personal opinions and hurt feelings. The author intermixes claims of prescience ("... as I predicted back in 19xx...") with portent-filled visionary statements of a very subjective future.

I haven't read much of Dave Winer's stuff, but it doesn't really seem to be much more than a series of self-promotional diatribes. Didn't he once describe Slashdot as a "cesspool"? Pot, kettle, black.

Anyway, there are much better alternatives if you're seeking high-tech journalism. Balance, integrity: you won't find it at davenet.

The overriding conclusing about Dave's rant:

[uradu]

This man can't write! The whole thing is one big stream-of-consciousness mess that completely detracts from anything he has to say. And please, could he make up his mind on Microsoft--either he hates them, in which case he should already stop cooperating with them all the time, or he doesn't, in which case he should just shut up.

Re:The overriding conclusing about Dave's rant:

[look]

"The whole thing is one big stream-of-consciousness mess that completely detracts from anything he
has to say."

Unfortunately, Dave considers this "freedom from editorial control" and the future of journalism (uneditted weblogs, that is).

Re:The overriding conclusing about Dave's rant:

[uradu]

> conclusing
> This man can't write!

And neither can I!

Embrace and Extend and Bastardize

[Anonymous Coward]

For those without a clue SOAP is nothing more than a bastardization of the XML-RPC protocol. Under MS influence the XML-RPC protocol was highly modified with no real value added except to provide MS with COM compatibility.

I was on the original SOAP discussion list during the specifications construction. I removed myself from that list when the protocol got out of hand.

The MS house was interested in named parameters, which is very stupid from a standpoint outside of COM.

To implement a SOAP based server you would have to actually be able to somehow read these parameters by a published interface (idl or whatever). Why do you think SOAP is so poorly supported by other languages. A COM component always has a published interface, yet my linux c program does not and no I do not wish to publish one either. Left to right calling conventions on the other hand are about as standard as it gets and named parameters a not needed.

The other problem is the usage of non spec DTD'S and such to describe the mark up. First of all a DTD is not necessary at all or ever. If you are building a two tiered app you have to know the data types you are passing are compatible anyhow. So call it what you will but it has only one implementation in my book, COM and MS.

CGI already causes this problem.

[tjpalmer]

Any other kind of server-side scripting, too.

- Tom

Re:Why SOAP is so important

[q000921]

Put simply, using SOAP, two or more 'alien-things' can communicate to each other as long as they agree on the SOAP protocol - which is the ONLY requirement when doing client/server using SOAP.

Sure CORBA, DCOM, COM+, Java, etc. allow you to enable two different components to talk to each other,

SOAP isn't an RPC/DO mechanism comparable to CORBA, DCOM, or RMI because SOAP doesn't specify how to encode many common datatypes found in programming languages. It doesn't even tell you how to encode arbitrary strings.

So, it's hard to say what SOAP is. It's not a mechanism for exchanging arbitrary XML documents (and you can do that much more easily via HTTP anyway). And it's not a mechanism for implementing even the simplest forms of RPC involving real programming languages. It's something that looks like an RPC mechanism but doesn't really deliver.

What it really is is whatever Microsoft does and because the spec is so incomplete, you can't reliably interoperate with it. What you can do is reverse engineer a little more easily. Let's be thankful for little favors, but let's not grow overly enthusiastic.

With SOAP, this is all eliminated. As long as the server publishes its API via the SOAP protocol, I can write my client to talk with the server using what ever I want. This frees me from having to 'embed' in my client a piece of the server -- thus there is no longer any 'hard-coupling' between two 'things'.

This stuff isn't new at all: people had dynamically typed remote interfaces and service descriptions for years. CORBA/DCOM/RMI actually represented a step backwards when they came out.

Dynamically typed remote interfaces and service descriptions are nice and have all sorts of benefits, but they don't eliminate coupling.

In short, using SOAP, we now enable a true 'smart' data-exchange-protocol between two systems such that development is now at the level of "data-exchange" rather than API, SDK, language, etc.

Smart data exchange would require actual smarts: rules, constraints, inferences. There is nothing in the SOAP spec or implementations that supports that. It's extremely naive to assume that those problems will get magically solved merely by using some complicated XML scheme for describing data and services.

The XML community is roughly where the Lisp community was in the 1960's: they are awed by the power and convenience of a universal syntax and dynamic type system and they haven't woken up to the fact that the problems themselves are hard and aren't solved just by having convenient, powerful data types.

Virtual Person?

[AdmrlNxn]

I am sorry but a business is not a person. NOt even compairable in a virtual manner. The main reason a business is around is to make money. Any other reason is bullshit. That is why businesses start, to grab a piece of the american dream.

Now in Microsofts case, they are a business trying to thrive because they have a vision. A vision that is unbeknownst to nearly everyone. Any competition that might stiffle and blemish this vision, this dream, is to be put out by any fair means necessary. That is exactly what they have done.

If a competeing business can't handle the competition then they should back down.

I am guessing you are American and as an American... Do you love all the rights and privlidges that come with? If so, then here is a comparable image.

Revolutionary War. Britian being the Americans competition. They had a bigger army and more supplies... We put up a fight and won.

War and Business are synonymous. If you don't have that mindset... you will lose. Microsoft isn't the Hannibal Lectur of the business world. They are just staying afloat. They have no reason to embrace and greet another business as if it were a neighbor. Unless that business can better their chances for dominance.

That is the business world.

If you see Microsoft as a murderer, fine. This is survival of the fittest. My money is on the team with the vision. The Microsoft Team. They have one damn good idea on how the NET should look, not how it is. I know where they are headed and frankly it is a great idea. I just wish that everyone could see this. Drop all their automatic-Microsoft-stereotypes and enjoy the ride.

~AdmrlNxn
Whistler is to Zeus as Linux is to Hercules

The opportunity of Soap

[SpanishInquisition]

What is it? Well just don't drop it and give the guy behind you an opportunity. Remember, just don't drop it (unless of course you are cyborg_monkey)
--

SOAP on a ROPE

[jasonk3]

I think it's funny that Microsoft called one of their SOAP tools the Remote Object Proxy Engine. Someone over there must still have sense of humor.

Yet he forgot...

[Sheeple Police]

to mention BizTalk. We all know Microsoft's SOAP implementation won't be the most compatible of them all. Heck, I develop with it, I know this myself. But he seems to overlook the fact that when Microsoft realizes a bug, a problem, a milieu if you will, they don't fix it. No, they release another program to do it for them. Honestly, this has it's own strength and weakness, weaknesses such as you now have to pay to "license" another peice of software (as with MS, it seems you can never own what you pay for), that it's not fully integrated into whatever other product suite, and that it can mean yet another peice of software to learn. However, the strength of having a dedicated development team on it, developing and extending the features and making sure that any single program doesn't get to feature rich (hint: this is where you make a crack about Word's feature bloat) balance those negatives out.

Which brings me to the topic at hand. BizTalk. Microsoft's goal with BizTalk is to serve as a translator to allow interop with XML documents. Now, you and I both know that a well written XSL can handle many of the features BizTalk does, and if you read into enough, that's really all BizTalk does is collect XML files, translate them with an XSL, and put the resultant XML files somewhere else. Now, tell me, how is this any different from SOAP/XML-RPC, in which the calls are transmitted and received through XML? Yes, Microsoft want it's spoonfed developers (sadly including me) to use their no doubt individual implentation which just happens to be different from everyone else. But they aren't going to isolate their developers, instead offering BizTalk to handle the translation from x,y, and z sources to MS Standard (ooh, shame on those rogue sources following a strict, compatible implentation rather than doing it the MS way!)

On the same vein, but for Linux, how long will it be until someone writes a set of libraries that handle translation between XML-RPC and whatever method a develop choses to implement SOAP to/from the MS standard on their end? It isn't that hard to see how the requests are formed, sent, and received (it's just XML data over HTTP), so surely someone will release a library or a set of XSL files. Yes, I know, this is more work, but this is not the end of the SOAP standard for open source developers, I don't believe, although from reading the article the author would seem likely to disagree with me.

Re:Yet he forgot...

[jasonk3]

I talked to Microsoft the other day about .NET for the company I work for...they couldn't tell me one advantage .NET had over an existing implementation of something like SQL server and a third-party XML data customization server.

The pre-sales guy kept saying over and over again "you can get your information anytime, anywhere"...he eventually admitted that .NET has virtually no advantage for a company with any significant investment in infrastructure.

Then what's the point?

[SuperKendall]

If you have to make new interfaces all the time, then why bother with something like SOAP? I could just as easily use some IIOP based communication if I'm going to have new interfaces everytime I make a change.

The way I predict SOAP interfaces changing is through an extension/deprication based mechanism. That is, when you need to make a change to the interface you add new parameters or methods, but leave the old ones there and mark them as depricated somehow (I don't know enough about SOAP to know how one could mark them). Then after some time you eliminate the old parameters or methods. That way the interface naturally evolves and you can support old and new clients at the same time.

Bug in bug reporting

[hey]

My 2 cents worth about developing under Microsoft... I found a bug in the C++ compiler - arrrg. Cost me tons of time. Then when I went to report the bug here: http://support.microsoft.com/Support/visualc/repor t ... its says "Bug Reporting Unavailable" (follow the link - its been broken for at least a week and still is). Since I can't report this bug it almost certianly won't be fixed in the next release arrrg.

By the way, what do you think? It would help me to have this bug fixed but it would also help the evil empire. Do you help them by reporting bugs?

Re:Bug in bug reporting

[cworley]

You've got to at least try to report the bug in some forum. If Microsoft's deaf ears are not accepting bug reports, then post it to the relevant newsgroup: you may be helping some other developer not waste their time as you did (and, you know Microsoft doesn't care how much time developers waste because of their bugs).

Re:Microsoft lost control of SOAP :)

[Dahan]

>> but Jon Bosak of Sun was the leader of the working group creating XML...

> Well ain't that just fascinating. Jon Bosak of Sun created SOAP?
> Funny, I don't see his name on the credits.

Ah, I see you have reading comprehension problems. Perhaps you might try reading SoftwareJanitor's post slowly and carefully. Especially the part that says "creating XML". Then go and read this. Pay careful attention to the part that says:

• Jon Bosak, Sun (Chair)

> I rest my case, you don't know what you are talking about.

The same could be said for you.

Re:Microsoft lost control of SOAP :)

[SoftwareJanitor]

Of course sheldon is a well known Microsoft apologist. Given Microsoft's normal way of doing things them just not getting in the way of IBM's changes would probably be counted as working with IBM.

SOAP is...

[pemerson]

By digging one more layer down, you can find this at W3:

Abstract

SOAP is a lightweight protocol for exchange of information in a decentralized, distributed environment. It is an XML based protocol that consists of three parts: an envelope that defines a framework for describing what is in a message and how to process it, a set of encoding rules for expressing instances of application-defined datatypes, and a convention for representing remote procedure calls and responses. SOAP can potentially be used in combination with a variety of other protocols; however, the only bindings defined in this document describe how to use SOAP in combination with HTTP and HTTP Extension Framework.