Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
Microsoft

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

The Opportunity of SOAP

Comments Filter:
  • by cworley ( 96911 ) on Friday March 02, 2001 @06:25AM (#389542)
    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.

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

    ~AdmrlNxn
    Whistler is to Zeus as Linux is to Hercules
  • >which is one instance of a dissatisfied Windows developer

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

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

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

    >Altura developed a Winsock implementation for the Macintosh

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

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

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

  • by scrytch ( 9198 ) <chuck@myrealbox.com> on Friday March 02, 2001 @12:50PM (#389545)
    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.
    --
  • >Okay, now I see you don't know what 'proprietary' means. You can find the definition here:
    http://www.dictionary.com/cgi-bin/dict.pl?term=pro prietary

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

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

    Did you read the link you supplied?

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

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

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

    Lets clear the smoke.

    If "two" (forget more for a second [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?"

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

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

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

    SOAP [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.

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

    [We'll skip the fact that SOAP, CORBA, [D]COM[+], and "Java" are a rather orthogonal [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 ...)

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

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

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

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

    Smoke: SOAP/XML is a great leap forward!

    Fact: Bubble Economies [metaphorsatwork.com] produce Bubble Technologies [w3.org] .

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

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

    -dB

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

    (And if Sun had really undestood the business model behind .NET, Java would have been handed off to a standards body, and there would be no XML.)
  • Don't forget COM+'s new TNA apartment model. -Jon

    Streamripper [sourceforge.net]

  • 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).
  • by Anonymous Coward

    I wish more Linux evangelists would use Soap.

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

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

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

    Praise be to Allah

    Indeed. Glory be To HIM.

  • 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.
  • Traditional RPC protocols also require you to statically bind to an interface (.h file, .java file, IDL file). This means that when an interface changes, you need to recompile. This sucks.

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

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

    -jon

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • At least in the J2EE copycat that .NET is.

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

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

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

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

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

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

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

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

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

    As I originally stated:

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

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

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

    Exactly the point of this thread. Thank you.

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

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

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

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

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

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

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

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

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

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

    I did ;)

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

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

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

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

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

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

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

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

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

    Maybe that solution would have satisfied the appeal court judges.

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

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

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

  • by q000921 ( 235076 ) on Friday March 02, 2001 @02:02PM (#389564)
    Traditional RPC protocols require one to know that a method is of the form:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • I stand corrected:

    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"


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

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

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

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

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

    You get something like:

    No site configured at this address

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

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

    I am interested in XML-RPC, though. Dave can
    do 'simple but effective'.
  • by garoush ( 111257 ) on Friday March 02, 2001 @06:58AM (#389575) Homepage
    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.
  • 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.

  • Thanks for the clarification. I knew that MIME attachments were supported by SOAP, but I wasn't sure of whether pure binary attachments - as opposed to encoded attachments like Base64 - were allowed, whether by SOAP or even HTTP. I haven't seen them used very often so I wondered if there was a reason for that.
  • Sorry about my english (I am spanish parlant) I agree 100% you that the real battle is on the server side and Microsoft need time (.NET) to do something? (I believe they don't know what) because windows 2000 is flawed. Distributed process and language interoperability are to be trashed in a few years, so I view in the future terminals (or ultra-thin-client at the client side) driven by servers (as has being done in the 'dinosaur era'), an enhanced TCP/IP, a message system-protocol as simple and efficient as possible (none of actual mess) to hold terminal to host and host to host interaction.

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

    I'll have to concur with the other AC reply [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.

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

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

    Anyway...

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

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

  • News flash:

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

    The good news is that the last living person without a sense of humour (DW) has finally passed on...
  • >Funny, I looked in the Microsoft Knowledge Base...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

    But MS does have a monopoly on the OS market.

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

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

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

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

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


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

    Now let me try again... and see if joubin [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.
  • $ telnet www.microsoft.com 80
    Trying 207.46.131.199...
    Connected to www.microsoft.akadns.net.
    Escape character is '^]'.
    GET / HTTP/1.0
    Host: www.microsoft.com

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

    (etc, etc...)
  • Thanks for quick trip down memory lane. :-)
  • Let's not waste anymore time with SOAP and legacy technologies and give our full opensource attention to the real future, java and jini.

    I forgot to include this link [sourceforge.net]. The link is to an open source OS that is built on the .net infastructure. It's written mostly in C and C#.
  • In the recent comments on the Microsoft trial , I came to the conclusion [slashdot.org] that Microsoft is the corporate equivalent of Hannibal Lecter. In my opinion.

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

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

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

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

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

    Sure it is based on XML markup; sure using CORBA, DCOM, etc. you can enable two object to talk to each other; and so fort. SOAP solves this communication/service problem buy promoting a business-logic instead of a technical-tool.
    ---------------
    Sig
    abbr.
  • by Sam Ruby ( 8995 ) on Friday March 02, 2001 @07:30AM (#389598) Homepage
    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/ [apache.org].
  • by Stu Charlton ( 1311 ) on Friday March 02, 2001 @07:54AM (#389605) Homepage
    Taking away the hype, here's a simple look at: "Why SOAP for RPC?"

    1. The real value comes from XML.

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

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

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

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

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

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

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

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

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

    2. SOAP's actual value (besides XML) is limited:
      • It's an envelope for an XML document (which can be used as an RPC call) that says "you should know these schemas in order to understand this message".
      • It defines a standard type encoding (for arrays, structs, etc)
      • Can target to specific proxies (actors) application extensions (XML namespaces & schemas)
      • SOAP runtimes will ease development for particular languages. Runtimes already exist for Java, .NET, and other languages.
    3. HTTP provides the final value-add in that it's ubquitious, firewall-friendly, and clear-text.
    4. Different quality of service needs do exist, so SOAP isn't dependent on HTTP.
  • 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 [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].
  • by IntlHarvester ( 11985 ) on Friday March 02, 2001 @07:57AM (#389607) Journal
    .NET is revolutionary for VisualBasic programmers, because it essentially puts them in the same territory as Java programmers. The cost of this, however, is that a huge chunk of their VB6 stuff breaks - the cost of turning VB into a 'safe' language.

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

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

    VB has lots of users behind it, and MS is planning to ride .NET in on VB programmers. Too bad Sun didn't come up with the idea of a ObjectBASIC for the Java Platform a couple years ago.
    --
  • by the_tsi ( 19767 )
    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...
  • I don't completely agree; XML doesn't really ship the semantics with the data any more than any other structured format. The XML is just data; in the end, code determines how that data is used.

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

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

  • by connorbd ( 151811 ) on Friday March 02, 2001 @10:04AM (#389611) Homepage
    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.

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

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

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

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

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

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

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

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

  • 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.
    ---
  • 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.
  • 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?
  • You can already invoke COM objects over HTTP. It's been there since MDAC 2.0 as I recall.

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

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

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

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

  • So the web is no longer a place of innovation?

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

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

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

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

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

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

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

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

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

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

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

    This will of course be critical with .Net and web services and such, because you don't want to break all your clients or they will call your stuff unreliable.
  • by Cardinal Biggles ( 6685 ) on Friday March 02, 2001 @08:57AM (#389640)
    3. HTTP provides the final value-add in that it's ubquitious, firewall-friendly, and clear-text. (emphasis added)

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

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

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

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

  • by linzeal ( 197905 ) on Friday March 02, 2001 @06:03AM (#389647) Homepage Journal
    SOAP is a lightweight protocol for exchange of information in a decentralized, distributed environment. It is an XML based protocol that consists of three parts: an envelope that defines a framework for describing what is in a message and how to process it, a set of encoding rules for expressing instances of application-defined datatypes, and a convention for representing remote procedure calls and responses. SOAP can potentially be used in combination with a variety of other protocols; however, the only bindings defined in this document describe how to use SOAP in combination with HTTP and HTTP Extension Framework

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

  • SOAP == Simple Object Access Protocol.

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

    Check here [w3.org] for more info.

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

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

  • 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?
  • 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.
  • by q000921 ( 235076 ) on Friday March 02, 2001 @10:55AM (#389670)
    Put simply, using SOAP, two or more 'alien-things' can communicate to each other as long as they agree on the SOAP protocol - which is the ONLY requirement when doing client/server using SOAP.

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

    SOAP isn't an RPC/DO mechanism comparable to CORBA, DCOM, or RMI because SOAP doesn't specify how to encode many common datatypes found in programming languages. It doesn't even tell you how to encode arbitrary strings [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.

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

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

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

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

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

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

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


    ---
  • by jasonk3 ( 313457 ) on Friday March 02, 2001 @06:11AM (#389675)
    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.
  • by Sheeple Police ( 247465 ) on Friday March 02, 2001 @06:14AM (#389677)
    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.
  • What dynamically types remote interfaces and service descriptions did "people" have before CORBA?

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

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

    Complete client code:

    (with-output-to-stream (socket) (print '(f 3 4)))

    (setq result (with-input-from-stream (socket) (read)))

    Complete server code:

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

    (with-output-to-stream (socket) (print result))

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

    How does CORBA represent a step backwards?

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

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

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

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

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

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

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

  • > conclusing
    > This man can't write!

    And neither can I!

  • I like XML-RPC which is sort of like "SOAP-Light"...it's very simple and to the point.
  • 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 pemerson ( 179241 ) on Friday March 02, 2001 @06:16AM (#389690)
    By digging one more layer down, you can find this [w3.org] at W3 [w3.org]:

    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.
  • by mbyte ( 65875 ) on Friday March 02, 2001 @06:19AM (#389692) Homepage
    Am I the only one who thinks this is kinda stupid ?

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

  • by SoftwareJanitor ( 15983 ) on Friday March 02, 2001 @06:21AM (#389693)
    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.

I THINK MAN INVENTED THE CAR by instinct. -- Jack Handley, The New Mexican, 1988.

Working...