[
Lists Home |
Date Index |
Thread Index
]
Amy Lewis wrote:
>
>...[re WSDL]
> So do parameterized URLs.
Parameterized URLs are something that travels across the wire at
runtime. They are analogous to the SOAP *message* which is generally
also very hard to read.
>...
>
> >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.
It is still my contention that the TCP binding of SOAP would not be any
more complicated than the HTTP binding. You make it sound like defining
connection setup/teardown is hard over TCP. It isn't. Look at Jabber for
example.
> ... 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.
That is not true at all.
http://docs.jabber.org/general/html/protocol.html
The Jabber specification talks in great detail about message format and
exchange patterns. And it says about connection roughly: "open two
connections, one each way."
> >> *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.
So? It will the first standardized version of SOAP.
> >> ... 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?
Because often the POST is going *out*. Here's what MSN Messenger's
documentation says today:
=============
What do I do if I have a firewall?
No matter what kind of firewall you have, you will need to configure it
to allow the computers within it to open outgoing TCP sockets to allow
your network users to use MSN Messenger Service. Computers on the
internal local area network will need access to the Domain Name System
(DNS) servers to resolve the names of external hosts such as
microsoft.hotmail.com. As network administrator, you need to do the
following:
• To enable the use of MSN Messenger Service: Open outgoing TCP Port
1863, and configure it so that sockets on this port are open for
extended periods of time.
• To enable the use of AOL Instant Messenger (AIM) integration with MSN
Messenger Service (Windows only): Open outgoing TCP Port 5190, and
configure it so that sockets on this port are open for extended periods
of time.
============
So MSN uses a new port so that by default it is blocked by strict
firewall policies. That's good, because a security hole in MSN could
expose the entire internal network, even if the connections are made
from the inside out.
A few years from now MSN will probably run on SOAP because it is the up
and coming generalized protocol substrate. If the SOAP world keeps going
the way it is going, Messenger will run on port 80 and everything will
look like an HTTP POST. What will the documentation look like then?
============
You need to buy a new firewall with built-in XML parsing capabilities.
Look for the following namespace within the SOAP:Body element.
============
>...
> >"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.
That's simply untrue. The SOAP RPC binding to HTTP could specify a port
number.
> ... It's a formatting standard for existing
> application protocols.
Yes, that's one way to look at it. In fact Mark Baker has an essay to
that effect. Unfortunately SOAP is an extremely poor "formatting
standard" for the HTTP protocol. Also since when is a "formatting
standard" a protocol at all. The question of what exactly SOAP is is
unanswerable because it is different things to different people. It's so
general and vague as to be a rorschach for the XML crowd.
> >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.
So you're saying it is perfectly appropriate for every new protocol from
now until infinity to use port 80. And when sysadmins start filtering on
XML content then it will be appropriate to define a new standard that
embeds S-expressions in the XML so that the new protocol is "firewall
friendly."
> >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;
I'm sorry. I don't see the requirment to add a SOAP header and SOAP body
to an XML message as "standardization". As a firewall admin that's the
*only thing* I can be confident that an arbitrary SOAP message will
have. That's it. The rest is optional. (unless I've missed something
recently)
>... that's just about all that the specs address
> with the wonderfully misleading HTTP binding and RPC patterns.
With friends like these, SOAP hardly needs enemies.
Paul Prescod
|
