[
Lists Home |
Date Index |
Thread Index
]
On Wed, Feb 20, 2002 at 09:32:43PM -0800, Paul Prescod wrote:
>Amy Lewis wrote:
>> 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.
>
>WSDL's verbosity strongly discourages human beings from attempting to
>read it.
So do parameterized URLs.
>> 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.
>
>Of course most example web services are in fact both idempotent and
>safe. No action is taken. But more important, most example web services
>tunnel a new addressing scheme through the Web. Behind a single web
>resource there are millions of "logical" resources. This is a violation
>of the Web Architecture which degrades the efficacy of Web logging,
>filtering and caching tools: in fact any Web intermediary.
This is an old addressing scheme. It's a very common addressing
scheme as well. If it doesn't fit REST, then it doesn't. It *is* very
widespread.
>Then why not use a TCP protocol? It would actually *reduce* the
>compexity of the spec, clear up the SOAPAction question. Clear up the
>"Web architecture" question. Improve performance.
Actually, no. SOAP addresses data format and message exchange
patterns, it's silent on connection setup/teardown, state versus
stateless, and many more things that an application protocol would have
to specify first. BEEP and Jabber both provide XML over TCP
application protocols (or application protocol toolkits, in the case of
BEEP), and spend most of their time there, very little (compared to
SOAP) on message format and exchange patterns.
>> *shrug* With a big honking SoapAction on them, in case anyone bothers
>> to look.
>
>SOAPAction is deprecated.
SOAPAction *will be* deprecated. 1.2 isn't released yet.
>> ... 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?).
>
>How can the network admin *even know* that such a server is running. It
>just looks like a standard HTTP POST, right? If their policy allows POST
>then it will be very hard for them to disallow SOAP.
How can a network admin *not* know?
A firewall designed by a competent admin doesn't simply allow any
incoming traffic on port 80. It allows incoming traffic on port 80
addressed to the web server. Incoming traffic on port 25 addressed to
the mail server. Incoming traffic on port 21 to the warez server.
Err, wait, I meant ftp. Oh, same thing.
Start by denying everything, then allowing specific things. A
corporate network running on an RFC1918 block with NAT in place doesn't
allow external clients to attach to internal servers without
port-forwarding, which the admin has to specifically enable.
>The very first line of an HTTP message has three things. A method name,
>which is supposed to vary, but is always the same for SOAP. A URI, which
>is supposed to vary based on the data you are working with, but is
>always the same for a particular SOAP component. All of the important
>goodies are in the body which is the *exact opposite* of the intent of
>the HTTP specification. Let me say that again. The whole design of HTTP
>1.1 was to make the "protocol" bits of the message as transparent as
>possible to intermediaries (including firewalls) so that they would not
>have to look at the body. SOAP puts all of the "protocol" (addressing
>and data manipulation) bits in the body.
Ah, okay, then it's failed already, and long ago. XML isn't magically
more obscure than MagicWord=xyzzy, and the usual result of the magic
word, regardless of whether it's carried in a named map or a tree, is
that nothing happens. Someone has to take action to make something
happen.
>> 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.
>
>Being "more general" than RPC is not a virtue in this argument. RPC is
>already too general. Now you will get SOAP messages and you don't even
>know whether to interpret them according to RPC conventions. That makes
>the sysadmin's job even more difficult.
Uh, I don't think so. Granted, the network admin you've set up here,
who allows free access from the internet to any box on the internal
network, is going to have a hard time. The professional paranoid who
opens ports on request, and who monitors what's getting installed into
his webserver's (or mailserver's) service tree already knows what's
coming in, and which modules it talks to based on that.
>> 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?
>
>My network admin allows me to run web services. In fact, I've built a
>desktop app that used XML-RPC so I've contributed to that situation. My
>network admin allows me to access the Internet. There's no way he can
>know whether the HTTP traffic from my desktop is from my web browser or
>my desktop apps. According to all estimates, SOAP messages will be
>zipping around the network every which way, as the new replacement for
>DCOM.
You should probably look for a new network admin. Incoming traffic on
port 80 is not hard to disambiguate from outgoing traffic on a high
port to some destination's port 80. If he can't manage that, he might
need to check some other career path.
>The apps will also be making outgoing calls. Corporations don't tend to
>think that desktop apps should be able to make any outgoing connection
>that the want (e.g. Morpheus). Because once the connection is made it is
>made, no matter who made it.
Then it's not executing alien code inside the protected network, is
it? SEP.
>Today sysadmins filter by ports (Morpheus is 1214). SOAP disables that.
Admins filter by source port, destination port, interface, source
address, destination address, protocol, connection state, statistics,
and in some cases mood and phase of the moon. Also content. Many
corps, for instance, filter on HTTP containing MIME, and strip out
attachments with detected viruses (they have to do this because of
webmail, which doesn't pass through the mailserver's virus detection
routines).
Rule of thumb: if you don't know how to monitor it, don't run it. It
is not the case that having a public webserver allows desktop
webservers to be accessed. It is generally not the case that I can
upload random noise from my desktop into the public webserver, either.
So applications using SOAP as the message format will have gone through
the same security deployment process (or lack thereof) as any other
application.
>"Well-known" port numbers exist for a reason. Can you offer a good
>reason why SOAP should use port 80? Other than firewalls?
So use 25. SOAP has to use some existing port, because it isn't an
application protocol. It's a formatting standard for existing
application protocols.
>Based on...parsing the XML text? Anyhow, why is the onus on the sysadmin
>to exclude. That's not the way the Internet has historically worked.
Quite true. It's the way it works now, though, and has been since lots
and lots of toys with random unused but vulnerable services were
attached. There's no going back, alas; we're no longer as trusting as
we were when the Morris worm hit.
>But more important, SOAP is a superset of RPC so it has no reliable
>internal structure, addressing model or even message pattern. It's
>transparent to humans but opaque to computers!
Horsefeathers.
The purpose of the silly thing is to provide standardization of content
in application protocols; that's just about all that the specs address
... with the wonderfully misleading HTTP binding and RPC patterns.
It's exactly as opaque to computers as a bag of name-value pairs, or
the parts of a MIME multipart/related message. If you'd like to give
REST a rest and recovery, try getting rid of MIME, which is equally
guilty of most of the alleged sins of SOAP.
Amy!
--
Amelia A. Lewis amyzing@talsever.com alicorn@mindspring.com
The law, in its majestic equality, forbids the rich as well as the poor
to sleep under bridges, to beg in the streets, and to steal bread.
-- Anatole France, "Le Lys Rouge"
|
