OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: [xml-dev] What does SOAP really add?

[ Lists Home | Date Index | Thread Index ]

I assume that SOAP isn't intended to do everything alone and that's the point of GxA and the WS-I. I admit to not having paid as much attention to this as I should have but think the following link will help clearify what Mike meant 
 
http://zdnet.com.com/2100-1104-274808.html

	-----Original Message----- 
	From: Paul Prescod [mailto:paul@prescod.net] 
	Sent: Sun 4/21/2002 6:46 PM 
	To: Mike Champion; xml-dev@lists.xml.org 
	Cc: 
	Subject: Re: [xml-dev] What does SOAP really add?
	
	

	Mike Champion wrote:
	>
	>...
	>
	> 1 - The obvious analogy is an envelope for snail mail.  It keeps a bunch of stuff in a
	> coherent package, it has an address and return address, and and provides some high-level
	> description of the contents. 
	
	SOAP does not, AFAIK, does not have a well-defined, interoperable
	concept of either forward address nor a return address. The forward
	address is expressed in the HTTP header.
	
	> ... Automating sorting equipment would presumably not be possible
	> unless there were conventions for where the address goes, which is the return address, what
	> size the envelope is, where the postage goes, etc.  SOAP does that for electronic messages;
	> whether the automatic routing, sorting, authentication/authorization, charging, encryption,
	> etc. "equipment" gets produced is speculative, but without something *like* SOAP, it would be
	> impossible.
	
	But how does SOAP:
	 * express the forward address
	 * express the return address
	 * express the size of the envelope
	 * help with routing
	 * help with sorting
	 * do authenticatoin/authorization
	 * do charging
	 * do encryption
	
	Of these, HTTP at least handles:
	 * forwarding
	 * size
	 * proxying (which is related to routing)
	 * authentication
	 * encryption (through https)
	
	> 2 - it's a standard because people use it and and people use it because it's a standard.
	> ...
	
	I'll buy this part of your argument when you convince me it does
	*something in particular* in a standard way. The only thing I've seen
	that it does reliably and interoperably is RPC over HTTP.
	
	> 3 - The intermediary mechanism seems like a bit of an afterthought, until one actually has to
	> think about how to get messages to from a legacy mainframe application to a Java PDA on a
	> train or plane somewhere.  There are an awful lot of hardware and software connections
	> between producers and consumers of web applications / services, and the assumption that every
	> node speaks HTTP to its neighbors is unrealistic.  Maybe every device SHOULD be on "the web",
	> but it isn't.  SOAP attempts to deal with that, it a platform / protocol / message
	> architecture-neutral way.
	
	Is it really the case that adding SOAP to a mainframe is easier than
	installing an HTTP server and thus putting it "on the web" (or at least
	on "a web")? If the particular mainframe variant hasn't got an HTTP
	server after all of these years, when will it get an interoperable SOAP
	implementation?
	
	Futhermore, SOAP anticipates the need to route but I don't see anything
	in it that specifies an interoperable way to do routing. Do you feel
	that a SOAP message could be interoperably routed from HTTP to JMS to
	SMTP to HTTP using only features of the SOAP specification?
	
	> 4 - The trend in SOAP really is to make it less of a "SOAP-RPC on steroids" and more of a
	> generic, transport-neutral, message architecture-neutral, low-level but theoretically
	> interoperable protocol. 
	
	Do you really think it is possible for a protocol to be entirely and
	truly transport, topology and message-architecture neutral? A "protocol"
	that doesn't care how it is transmitted, whether it will return a result
	etc. sounds more like a "file format" than a protocol to me. i.e. MIME
	expressed in XML.
	
	 Paul prescod
	
	-----------------------------------------------------------------
	The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
	initiative of OASIS <http://www.oasis-open.org>
	
	The list archives are at http://lists.xml.org/archives/xml-dev/
	
	To subscribe or unsubscribe from this list use the subscription
	manager: <http://lists.xml.org/ob/adm.pl>
	
	





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS