Slashdot Mirror
The Opportunity of SOAP
A reader writes: "There's an interesting piece on DaveNet concerning SOAP and some of Dave's predictions for it. He also talks about SOAP being in a flexible phrase, and the potentials for it, if it is used correctly. The point about the multiplicity of Dot.Nets is a good mental exercise too. Will development happen that way?"
Put simply, using SOAP, two or more 'alien-things' can communicate to each other as long as they agree on the SOAP protocol - which is the ONLY requirement when doing client/server using SOAP.
Sure CORBA, DCOM, COM+, Java, etc. allow you to enable two different components to talk to each other, but those technologies do it in such a way that you must have a 'piece' of the server (called the client) to be delivered and used by the client developer. Thus, to talk with a 'server' you must meet the needs of the 'server' when using CORBA, DCOM, COM+, Java, etc.
With SOAP, this is all eliminated. As long as the server publishes its API via the SOAP protocol, I can write my client to talk with the server using what ever I want. This frees me from having to 'embed' in my client a piece of the server -- thus there is no longer any 'hard-coupling' between two 'things'.
In short, using SOAP, we now enable a true 'smart' data-exchange-protocol between two systems such that development is now at the level of "data-exchange" rather than API, SDK, language, etc.
---------------
Sig
abbr.
Karma stuck at 50? Add 2-5 inches.. err.. 2-5x Karmas Count to your pen1es.. err.. Karma all naturally and private
XML as a data representation has 2 major differences between it and the other more popular RPC protocols:
- It ships semantics with the data (i.e. it's a semantic data stream)
- It does not require static interface for 2 endpoints to communicate.
Let me elaborate:foobar(int a, int b, char[] c)
I.e., you need to know the positions of the parameters, and their types.With XML, each parameter is defined by a "tag". This allows position independence -- one only has to state the name of the parameter that the piece of data is for. (Insert analogy to Smalltalk method parameters here.)
With XML, the interface for an RPC is defined by an XML Schema Definition, which is just a type/structural description of an XML document. No binding. No recompiling. No registry hell due to immutable COM interfaces.
XML RPC frees you from having to use a standard object model, or a standard language. You can implement an XML RPC endpoint in ANYTHING you want -- there's no model to bind to. Every call is dynamic.
-Stu
.NET is revolutionary for VisualBasic programmers, because it essentially puts them in the same territory as Java programmers. The cost of this, however, is that a huge chunk of their VB6 stuff breaks - the cost of turning VB into a 'safe' language.
.NET really doesn't give you anything except a 1.0 RSN platform. The features it does have (including SOAP and 'web objects') could be added to Java (and probably will be) by the time MS ships.
.NET doesn't get pigeonholed as a "VisualBasic" technology, and so that MS can tout it's language-independance. Plus it gives them the JUMP Java migration program.
.NET in on VB programmers. Too bad Sun didn't come up with the idea of a ObjectBASIC for the Java Platform a couple years ago.
On the other hand, if someone has already invested in Java,
My feeling is that C# is really there for propaganda value, both so that
VB has lots of users behind it, and MS is planning to ride
--
Business. Numbers. Money. People. Computer World.
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
from http://www.w3.org/TR/SOAP/
An Education is the Font of All Liberty
SOAP isn't an RPC/DO mechanism comparable to CORBA, DCOM, or RMI because SOAP doesn't specify how to encode many common datatypes found in programming languages. It doesn't even tell you how to encode arbitrary strings.
So, it's hard to say what SOAP is. It's not a mechanism for exchanging arbitrary XML documents (and you can do that much more easily via HTTP anyway). And it's not a mechanism for implementing even the simplest forms of RPC involving real programming languages. It's something that looks like an RPC mechanism but doesn't really deliver.
What it really is is whatever Microsoft does and because the spec is so incomplete, you can't reliably interoperate with it. What you can do is reverse engineer a little more easily. Let's be thankful for little favors, but let's not grow overly enthusiastic.
This stuff isn't new at all: people had dynamically typed remote interfaces and service descriptions for years. CORBA/DCOM/RMI actually represented a step backwards when they came out.
Dynamically typed remote interfaces and service descriptions are nice and have all sorts of benefits, but they don't eliminate coupling.
Smart data exchange would require actual smarts: rules, constraints, inferences. There is nothing in the SOAP spec or implementations that supports that. It's extremely naive to assume that those problems will get magically solved merely by using some complicated XML scheme for describing data and services.
The XML community is roughly where the Lisp community was in the 1960's: they are awed by the power and convenience of a universal syntax and dynamic type system and they haven't woken up to the fact that the problems themselves are hard and aren't solved just by having convenient, powerful data types.
Am I the only one who thinks this is kinda stupid ?
.. for what reason ? right ! to go behind firewalls ! So .. I build my firewall, allow only HTTP, then they start using it as a tunnel device !!?
I mean, they are basicly doing tunneling corba/RMI/etc. calls over HTTP