The Opportunity of SOAP 152
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?"
On hold with Microsoft for 6 months (Score:3)
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:Virtual Person? (Score:1)
~AdmrlNxn
Whistler is to Zeus as Linux is to Hercules
Re:On hold with Microsoft for 6 months (Score:1)
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
>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:Yet he forgot... (Score:3)
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:On hold with Microsoft for 6 months (Score:1)
http://www.dictionary.com/cgi-bin/dict.pl?term=pr
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:Um... (Score:2)
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 :) (Score:2)
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 (Score:2)
Lets clear the smoke.
If "two" (forget more for a second [w3.org]) "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 [vub.ac.be]..
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 [slashdot.org] . [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 [w3.org], and XML-RPC [xml-rpc.com], both provide a means for one GAGA to send messages to another GAGA, even if the two GAGA have discovered [microsoft.com] each other for the very first time. And this messaging protocol [w3.org], based on the well-understood [there!] request [w3.org]-reply [w3.org] paradigm, and utilizing a standard XML-based message container [w3.org], delivers SOAP-compliant [w3.org] 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 [dictionary.com] 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 [amazon.com] 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 [amazon.com]!)] .
Lets just take Java's RMI [sun.com] 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 [sun.com], a remote reference. Any object you say? No. Objects which have been registered with a Registry/Directory Service ( UDDI [microsoft.com] anyone?) Then you pass the method invocation message to the remote object and a bit of infrastructure on the receiving end maps [sun.com] 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 [sun.com] which is analogous to what SOAP specifies.
So:
Smoke: SOAP (& XML-RPC) are distributed object technologies! [This goes beyond Smoke and verges on GAGA [dictionary.com] 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 [w3.org] 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 [seajug.org], 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 [metaphorsatwork.com] produce Bubble Technologies [w3.org] .
Re:Um...( a little more detai on what SOAP is) (Score:1)
I still don't get what makes SOAP a "lightweight protocol".
-dB
J2EE is a sub-set of .NET (Score:1)
(And if Sun had really undestood the business model behind
Re:SOAP on a ROPE (Score:1)
Streamripper [sourceforge.net]
Re:Um... (Score:2)
Soap Use (Score:2)
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... (Score:1)
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 [brown.edu] enough.
Indeed. Glory be To HIM.
Re:Then what's the point? (Score:2)
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 (Score:2)
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
Re:On hold with Microsoft for 6 months (Score:1)
...
>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.
Microsoft is irrelevant (Score:1)
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
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:On hold with Microsoft for 6 months (Score:1)
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.
>
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 (Score:1)
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:Microsoft lost control of SOAP :) (Score:2)
Re:Binary Data? (Score:2)
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 (Score:3)
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.
too simple (Score:1)
Um... (Score:1)
What is SOAP? They don't seem to explain it at all.
Re:SOAP's real technical benefits (Score:2)
Re:Then what's the point? (Score:2)
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? (Score:2)
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... (Score:1)
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?
Re:Um... (Score:2)
from Miscro$oft [microsoft.com] (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 [w3.org]( re SOAP 1.1):
"SOAP can potentially be used in combination with a variety of other protocols"
Re:Um... (Score:1)
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... (Score:1)
They won't do it right. (Score:2)
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'.
Why SOPA is so important (Score:4)
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: (Score:2)
Re:Microsoft lost control of SOAP :) (Score:2)
Re:Binary Data? (Score:1)
Re:Microsoft is irrelevant (Score:1)
Re:Um... (Score:1)
I'll have to concur with the other AC reply [slashdot.org] 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 [slashdot.org]. 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:On hold with Microsoft for 6 months (Score:1)
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:Hall o' mirrors (Score:1)
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...
Re:On hold with Microsoft for 6 months (Score:1)
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.
VS.NET development (Score:1)
Re:Yet he forgot... (Score:2)
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!!! (Score:1)
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 (Score:1)
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 (Score:2)
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 (Score:1)
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.
Re:GAGA For Bubble Technologies (Score:1)
Now let me try again... and see if joubin [slashdot.org] 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.
Never heard of virtual hosts ? (Score:1)
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!! (Score:1)
Re:Um... (Score:2)
I forgot to include this link [sourceforge.net]. The link is to an open source OS that is built on the
MS? ughh (Score:2)
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 (Score:1)
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.
Open Source has also discovered SOAP (Score:3)
SOAP's real technical benefits (Score:5)
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.
Re:Why SOAP is so important (Score:2)
There are open-source SOAP implementations all over the place. Somebody has already mentioned the xml.apache.org/soap [apache.org] SOAP server, and there's a nice Perl SOAP client at Soap::Lite [soaplite.com]. A search for "SOAP XML" on Google will provide a plethora of pinatas...I mean matches.
My company [velocigen.com] 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 [velocigen.com].
Re:Um... (Score:4)
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
--
SOAP (Score:2)
-Chris
...More Powerful than Otto Preminger...
XML: No silver bullet (Score:2)
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.
Hall o' mirrors (Score:4)
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
Binary Data? (Score:2)
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:Hannibal (Score:2)
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.
needs to do some research... (Score:2)
---
Re:Um... (Score:2)
Re:SOAP (Score:2)
Re:Microsoft lost control of SOAP :) (Score:2)
Re:Microsoft lost control of SOAP :) (Score:2)
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 :) (Score:2)
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 :) (Score:2)
Re:Then what's the point? (Score:2)
Re:SOAP's real technical benefits (Score:2)
It was originally called DCOM tunneling, but was recently renamed to COM Internet Services.
Bruce Schneier agrees with you. (Score:2)
--
You really don't have a clue, do you? (Score:2)
--
What planet is he on? (Score:2)
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.
Re:On hold with Microsoft for 6 months (Score:2)
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:XML: No silver bullet (Score:2)
This will of course be critical with
Re:SOAP's real technical benefits (Score:3)
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 (Score:2)
Speaking of clear messaging (Score:2)
To anyone reading this: learn how to communicate, or don't bother to learn how to code.
--
Re:Um... (Score:4)
from http://www.w3.org/TR/SOAP/
Re:Um... (Score:2)
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 [w3.org] for more info.
Re:Hannibal (Score:2)
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.
Re:Yet he forgot... (Score:2)
So tell me are all MS employees as smart and brave as you?
Re:Um... (Score:2)
The overriding conclusing about Dave's rant: (Score:2)
Re:Why SOAP is so important (Score:4)
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 [w3.org].
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.
Re:Um... (Score:2)
Confused? You won't be ... after this week's episode of SOAP.
---
SOAP on a ROPE (Score:3)
Yet he forgot... (Score:3)
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:A Couple Of Questions (Score:2)
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.
Re:A Couple Of Questions (Score:2)
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.
Then what's the point? (Score:2)
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.
Re:Binary Data? (Score:2)
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:The overriding conclusing about Dave's rant: (Score:2)
> This man can't write!
And neither can I!
Re:SOAP's real technical benefits (Score:2)
Re:Microsoft lost control of SOAP :) (Score:2)
SOAP is... (Score:3)
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.
Re:Um... (Score:4)
I mean, they are basicly doing tunneling corba/RMI/etc. calls over HTTP
Re:Um... (Score:3)
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.