Slashdot Mirror
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?"
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.
When I die, please cast my ashes upon Bill Gates -- for once, make him clean up after me!
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.
--
I've finally had it: until slashdot gets article moderation, I am not coming back.
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.
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.
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?"
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.
[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 ...)
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 .
member, alphazero LLC | Geneve, Confederation Helvatic | bi-ped
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).
Je ne parle pas francais.
I wish more Linux evangelists would use Soap.
After all, 5 minutes once a day with Soap will do wonders for your interpersonal skills!
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.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
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
Remember Amalek.
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.
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.
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:".
Yup, dynamic interfaces are nice. Of course, lots of systems had them before CORBA and DCOM side-tracked the industry.
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.
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.
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.
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.
War is necrophilia.
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.
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.
War is necrophilia.
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"
I don't mean to Microsoft bash, but...
/' or
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
'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'.
If you say, "now I'll be modded down because of X", I'll happily oblige.
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.
Karma stuck at 50? Add 2-5 inches.. err.. 2-5x Karmas Count to your pen1es.. err.. Karma all naturally and private
I wish some of my coworkers around here would take advantage of the opportunity of SOAP.
-- Dr. Eldarion --
I could care less. It was the work of creating the SOAP spec 1.1 that Software Janitor was whining about.
"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.
War is necrophilia.
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.
"It is a greater offense to steal men's labor, than their clothes"
Let's not waste anymore time with SOAP and legacy technologies and give our full opensource attention to the real future, java and jini.
.net infastructure. It's written mostly in C and C#.
I forgot to include this link. The link is to an open source OS that is built on the
Like sex? Read and write about it! Indecent Blogging
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?
"It is a greater offense to steal men's labor, than their clothes"
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/.
- Sam Ruby
XML as a data representation has 2 major differences between it and the other more popular RPC protocols:
- It ships semantics with the data (i.e. it's a semantic data stream)
- It does not require static interface for 2 endpoints to communicate.
Let me elaborate: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.)
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.
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.
-Stu
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.
.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.
.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.
.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.
.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.
On the other hand, if someone has already invested in Java,
My feeling is that C# is really there for propaganda value, both so that
VB has lots of users behind it, and MS is planning to ride
--
Business. Numbers. Money. People. Computer World.
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...
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.
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
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.
In the course of every project, it will become necessary to shoot the scientists and begin production.
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.
"It is a greater offense to steal men's labor, than their clothes"
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.
---
DO NOT DISTURB THE SE
I see the crazies are out in full force today...
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.
Vintage computer games and RPG books available. Email me if you're interested.
That's fascinating, considering Microsoft worked with IBM to implement those changes.
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.
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.
Heh. Well I say it's better to be a paid troll then an idiot who does this for free. :)
I don't understand. Why are you disagreeing and then saying exactly the same thing as I commented?
Schneier voiced exactly that opinion in a recent Cryptogram.
--
Xenu loves you!
--
Never underestimate the relief of true separation of Religion and State.
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.
To anyone reading this: learn how to communicate, or don't bother to learn how to code.
--
It's rare that you're presented with a knob whose only two positions are Make History and Flee Your Glorious Destiny.
from http://www.w3.org/TR/SOAP/
An Education is the Font of All Liberty
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.
---- Den ene knappen er powerknapp, den andre er Bender voice knapp "Bite My Shiny Metal Ass"
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.
"It is a greater offense to steal men's labor, than their clothes"
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?
War is necrophilia.
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.
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.
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.
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.
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.
Confused? You won't be ... after this week's episode of SOAP.
---
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
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.
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.
Information is the catalyst for revolution
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:
Complete server code:
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.
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.
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.
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.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
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.
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.
Am I the only one who thinks this is kinda stupid ?
.. 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 !!?
I mean, they are basicly doing tunneling corba/RMI/etc. calls over HTTP
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.