[
Lists Home |
Date Index |
Thread Index
]
- From: Uche Ogbuji <uche.ogbuji@fourthought.com>
- To: Michael Fitzgerald <mike@wyeast.net>
- Date: Fri, 22 Dec 2000 13:20:24 -0700 (MST)
> However, I think of SOAP as merely an XML document, not a transport
> protocol. Any implementation that processes such a document handles the
> transport. Alone it can't do much. SOAP is a driver, not a car. E.g., HTTP
> physically moves a copy of content on a server in Kalamazoo to my browser in
> Oregon with a GET method. SOAP alone does nothing of the sort.
Wow. This is a big misconception. HTTP, too is nothing but data.
Believe me, I've spent more time that I'd like in the HTTP RFCs and I can
assure you they have _no_ information on how to get your content from
Kalamazoo to Oregon.
The RFC defines a format for bytes that can be placed in TCP datagrams.
You set up your Web server to listen on a socket (TCP/IP) level, and
if a packet comes on a particular port (TCP/IP level), usually 80, your
server retrieves the packet (TCP/IP level), and then looks at the *data*
in the packet, which is HTTP:
"GET /myfoodoc HTTP/1.1"
etc.
So, you see, HTTP and SOAP are both data formats.
> I also believe SOAP encoding is there as yet another convenience. It's there
> if I want it, but I don't have to use it, and the SOAP Body allows me a lot
> of flexibility without it.
Like it or not, by including it in the SOAP protocol spec, they have
given the SOAP serialization special standing. This is what I think is a
bad idea (especially since it's hardly my favorite serialization).
--
Uche Ogbuji Principal Consultant
uche.ogbuji@fourthought.com +1 303 583 9900 x 101
Fourthought, Inc. http://Fourthought.com
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python
|
