[
Lists Home |
Date Index |
Thread Index
]
On Friday 31 January 2003 18:33, Mike Champion wrote:
> On Fri, 31 Jan 2003 11:57:43 -0500, Rich Salz <rsalz@datapower.com> wrote:
> > SOAP over HTTP is architecturally no worse than HTTP POST: both are
> > sending data and requesting that a server act upon it.
>
> Yup. Is SOAP in an incompetently designed application and incompetently
> administered environment any worse than CGI, ASP, or any other tool for
> coupling client processing with server-side code via HTTP?
One point of difference, I believe, is that CGI/ASP over HTTP POST is usually
used for human interactions - there is an HTML page somewhere with a form
that specifies that POST; it's a very visible thing for administrators to
consider.
However, when that POST is hidden inside a REST Web service client, or it's
SOAP over HTTP from a SOAP client, there is a danger that it can slip in
unexpectedly.
So leave port 80 outgoing open on your workstation cluster, but not incoming.
Web services that are the only instance of their kind - eg, where the API in
use is one specific to that service, rather than an instance of a general
service - could well all sit on the same general 'Web service over HTTP'
port, since they are served from Out There on the Internet. A firewall admin
wanting to select which ones his users can access is doing a similar task, in
effect, to a firewall admin who wants to limit what Web sites they can
access, so it's fair to expect him to peek inside the HTTP headers enough to
look at the URL, and the destination IP address.
That one port for general Web services might be best kept away from port 80
for a number of reasons; it is conceptually distinct from the human oriented
communications on port 80, for a start.
But an HTTP-based protocol for, say, instant messaging should have a port
unto itself where firewall admins can selectively enable or disable incoming
traffic to their workstation cluster!
ABS
--
A city is like a large, complex, rabbit
- ARP
|
