[
Lists Home |
Date Index |
Thread Index
]
On Wed, Feb 20, 2002 at 04:39:38PM -0800, Paul Prescod wrote:
>1. SOAP tools encourage you to generate the network interface for your
>service from the implementation of the business logic. This is
>advertised as the *core Web Services feature* of Visual Studio.NET. Even
>if one is deeply in love with CORBA one usually edits the IDL
>implementation by hand and then generates the stub, not the other way
>around. For a real, serious, public app, auto-generating your network
>interface from your implementation is wrong on so many levels that I
>don't even know where to begin.
Umm. SOAP/XML Protocol does not require that toolkits generate WSDL
from interfaces, or that they generate stubs from WSDL, or in fact
anything about the deployment process.
That this argument is made in the marketing literature merely shows
that there are a large number of {programmers|development tool
purchasers} who find the premise attractive.
The existence of helpful IDEs, even if they break certain programming
principles near and dear to you (and to me, btw ... I agree completely
that offering this sort of silliness is a bad way to design services),
has nothing to do with the protocol definition.
>2. SOAP lies. HTTP is an application protocol, not a transport protocol.
No.
SOAP, in RPC mode, uses HTTP POST to submit a complexly structured set
of parameters, which may or may not be easily expressible using the
traditional name-value pairs associated with a POST. As a POST, it
implies non-idempotent processing. An action will be taken. Pure HTTP
so far, extending parameter syntax for enrichment of expression. SOAP,
in RPC mode, also implies that there is some processor sitting there
with a method having a particular name that is going to perform
operations with semantics related to the name of the first child
element of the Body. But, in fact, it don't have to. The various bits
and pieces specify that a message with a particular structure is
received, and a message with a particular response is returned. The
specs leave the meaning (semantics) of how those messages are related
to the a) implementors or b) imagination of the implementors.
SOAP, in message/document mode, uses HTTP post to submit a complexly
structured message (which may not be at all similar to HTTP parameters)
in order to initiate some process, said process being defined to return
a message with given syntax. Further than that, deponent sayeth not.
It may be a nonstandard use of HTTP, but it certainly breaks no rules,
and in fact is moderately RESTful.
>It has syntax and semantics, just as XML has syntax and semantics.
What are the semantics of XML? XML is syntax ....
>Imagine if someone asked you to submit a purchase order in some ebxml
>schema and you generate a valid instance but you actually put all of the
>"real" information in comments. The PO stuff is just 0's and empty
>fields. And maybe you've done this because you've colluded with someone
>on the "inside" to send the information this way instead of the regular
>way. They told you that if you sneak it through in this way then it will
>bypass the company's screening and business logic and they'll make sure
>it gets approved at whatever price. This is what SOAP does to firewalls.
>It lies to them. It says: "I'm HTTP traffic. I'm doing a POST. Check the
>HTTP specification to know what that means." Jabber, BEEP and many other
>XML protocols do not do this. They are defined at the TCP level as is
>logical. Routing SOAP over HTTP is a way for someone inside the company
>and someone outside the company to collude to disable the RPC-filtering
>features of the service.
This is fairly stiff. Perhaps it was the original intention of SOAP.
How one explains the bindings to SMTP, to EJB, to JMS, and so forth, is
less than clear.
HTTP is *a* binding for SOAP. It is the premier binding, the most
visible, because HTTP is widely deployed, and SOAP fits easily into the
HTTP model: POST a request, receive a response. SOAP doesn't specify
what lies on the processor side of that.
*Marketing* dorks certainly lie like this, hoping to sell product to
other marketing dorks and get around the evil network-admin BOFH
geekatroids who don't let said marketing dorks park their Win95 boxes
on the internet freely. I doubt, though, that you're going to find
very many deployments that actually sidestep firewall policy in this
fashion, 'cause the developers *do* talk to, and have (some) respect
for the network admins.
>SOAP lies both about what it is doing (POST to do getStockQuote) but
A POST containing standard HTTP parameters that returns a stock quote
is different how?
>what it is working with. "Ignore the component behind the curtain. It
>isn't working with millions of resources that really should have URIs.
>It's just one resource. One big fat honking resource. Really." If SOAP
>ran on TCP it would not need to feel obliged to obey the rules of the
>Web and HTTP. But it doesn't.
Actually, it runs on all sorts of things. Including jabber and BEEP.
>Maybe some people don't know that Schneier took on SOAP before in a
>little bit more depth. He said:
>
>"That's right. Those pesky firewalls prevent applications from sending
>commands to each other, so SOAP lets vendors hide those commands as HTTP
>so the firewall won't notice."
*shrug* With a big honking SoapAction on them, in case anyone bothers
to look. And *I* can't deploy a service into the corporate webserver
without approval of the admins. Maybe this is different in
cloud-cuckoo land.
>Roy Fielding says:
>
>"Then what you should be doing is figuring out why HTTP makes it through
>firewalls, even though firewalls predate HTTP. The theory that these
>protocols will be able to get through firewalls just because they are
>running on top of HTTP is just plain wrong."
Correct. Marketing spin.
>"The firewalls exist to protect users. Developers advocating
>generic RPC tunneling through firewalls are serving their own interests,
>not
>that of the users."
Fielding, like Schneier, here seems to confuse marketing droids with
developers. The two are not the same. If there is a network admin in
the world who allows free deployment of servlets, components, or
whatever into the corporate firewall, he ought to be fired for
incompetence *before* the first SOAP server gets dropped in (on top of
the NCSA finger CGI, perhaps?).
>If I were Fielding and I carefully designed HTTP to be transparent and
>thus more secure, I would be extremely annoyed to see SOAP hop on my
>bandwagon. The only saving grace is that it will fail and be shut down
>at the firewall again within a year.
Sorry, could you explain how SOAP is defeating transparency? It's
expanding the syntax of POST parameters. In the HTTP binding, which is
the most visible, but not at all the only binding.
>3. SOAP is RPC.
No.
No, no, no. In fact, SOAP as RPC, in my opinion, has a very limited
lifetime (just as SOAP over that horrible application protocol with its
i18n incompetence has, I hope, a short lifetime). SOAP as messaging
has a lot of potential, and is increasingly a direction of development.
>Fielding:
>
>"Architects use protocols to enable a defined set of communication. The
>degree to which that communication is visible to intermediaries
>determines
>whether or not it can be safely passed through a firewall. Now what is
>it about HTTP that makes it different from RPC, and thus safe for
>transfer
>through firewalls?"
>
>Schneier says:
>
>"DCOM is Microsoft's main protocol for inter-application communication.
>It's not just used by programs that are intended to be servers; it's
>used for all sorts of desktop communication and remote access. The
>result is that an average machine has dozens of programs using DCOM.
>Mine shows 48, ranging from "Microsoft PowerPoint Presentation" to
>"logagent" and including the catchily named
>"{000C101C-0000-0000-C000-000000000046}"; you may be able to list yours
>by bringing up a Command Prompt and typing "dcomcnfg"."
>
>"Now, there are lots and lots of ways to secure DCOM applications, so
>maybe all of those applications are happily responding only to
>authenticated requests from the local machine. On the other hand, there
>are lots and lots of ways to make DCOM applications insecure, so maybe
>one of them is just waiting for somebody to send it an entirely
>unauthenticated request to overwrite selected files on my hard disk."
>
>Now in two years, if Microsoft is right that SOAP is the way of the
>future, how many desktop apps will you have on your machine running
>SOAP? MSN Messenger, maybe Outlook, maybe a P2P app, etc.
On your *desktop*? Does your network admin let you run web services
exposed to the internet? Shouldn't he be looking into "would you like
fries with that" training, if so?
>What kind of insane system administrator would trust that the 48 SOAP
>apps on your desktop are secure enough to allow access from outside the
>firewall? What he's going to do?
Refuse access, of course. Just as HTTP doesn't go through to your
probably-insecure desktop web server. Duh.
>Because SOAP is *so generic* it is essentially impossible to understand
>what is going on by knowing merely that there are SOAP packets flowing
>across the network. SOAP has none of the application semantics of HTTP
>which allow one to know, for instance, that barring tunnelling or a bug,
>a GET coming from the outside in is safe.
But a POST isn't. And SOAP uses POST in the HTTP binding.
>Note that I said barring tunnelling. Once we agree that what SOAP does
>is legit we've opened the door to tunnelling and thenceforth, all bets
>are off. Maybe GET sometimes means POST in the future. Maybe PUT means
>GET. The precedent has been set. Any corporation in its right mind would
>have a strong policy against tunnelling and SOAP is tunnelling.
Most corporations have a strong policy in favor of certain kinds of
tunnelling, VPN being the prime example. But you mean application
tunneling over application protocols, in this case? And if the
tunneling isn't hidden, why should it be difficult to exclude? And
*why*, for heaven's sake, would you be allowing untrusted boneheads to
expose services--even HTTP GET only--to the internet?
>Both Fielding and Schneier make a point about the *generality* of RPC
>protocols. And Fielding also makes a point about the opacity of RPC
>protocols.
Which has what to do with SOAP? SOAP is transparent, SOAP is not
necessarily RPC. Reading XML is no harder than reading name-value
pairs.
>So to say it "isn't RPC versus REST" is to miss the point. These two
>people who know ten times more than I do about protocols and security
>both claim it is *entirely about RPC*.
Which is fine. But SOAP isn't about RPC.
Amy!
--
Amelia A. Lewis alicorn@mindspring.com amyzing@talsever.com
The one thing you can't trade for your heart's desire is your heart.
-- Miles Vorkosigan
|
