RE: non-outcry over eBay SOAP interace

Yes, I know.  I view this as very good news.  I also see the
existance of these interoperability issues as evidence of how
different the architectural positions were originally.  I am
very happy that these efforts are being made to bridge the gaps.

-bryan

-----Original Message-----
From: Ugo Corda
To: Thompson, Bryan B.; Cutler, Roger (RogerCutler) ;
www-ws-arch-request@w3.org; Newcomer, Eric ; He, Hao ; Michael Champion 
Cc: www-ws-arch@w3.org
Sent: 2/14/2004 3:01 PM
Subject: RE: non-outcry over eBay SOAP interace

Bryan,
The SOAP/HTTP interoperability examples you give below are already
addressed or being addressed:

- WSDL understanding the concept of idempotent

There is an open action item in the WSD WG to mark safe operations (I
imagine it could be extended to mark idempotent operations). See the
latest minutes at
http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0076.html.

- providing for description of native HTTP methods

See SOAP 1.2, Part 2, sec. 6.4

- having a means of binding parameters onto URIs that is compatible with
the use of URIs for web resources

See SOAP 1.2, Part 2, sec. 4.1.1


Ugo

> -----Original Message-----
> From: www-ws-arch-request@w3.org 
> [mailto:www-ws-arch-request@w3.org] On Behalf Of Thompson, Bryan B.
> Sent: Saturday, February 14, 2004 11:12 AM
> To: 'Cutler, Roger (RogerCutler) '; 
> 'www-ws-arch-request@w3.org '; 'Newcomer, Eric '; 'Thompson, 
> Bryan B. '; 'He, Hao '; 'Michael Champion '
> Cc: 'www-ws-arch@w3.org '
> Subject: RE: non-outcry over eBay SOAP interace
> 
> 
> 
> Eric,
> 
> I also appreciate the perspective.
> 
> > if you look at the HTTP spec, you can see that it was designed to be
> > extended, even for things such as custom interfaces
> 
> Yes.
> 
> > and SOAP is in  practice what the industry has settled upon as that 
> > extension.
> 
> Except that it is more replacement than extension.
> 
> My biggest problem with SOAP is that it is not designed as an 
> extension of the existing web architecture.  It's fine for a 
> lot of what people are interested in doing, but extending web 
> architecture is what I am interested in doing.  To meet that 
> goal there would have to be better support for 
> interoperability across SOAP and HTTP native interfaces.  
> E.g., WSDL understanding the concept of idempotent, providing 
> for description of native HTTP methods, and having a means of 
> binding parameters onto URIs that is compatible with the use 
> of URIs for web resources.  In my mind, you should be able to 
> address a URI using either SOAP and+or HTTP - depending on 
> its description.
> 
> -bryan
> 
> -----Original Message-----
> From: www-ws-arch-request@w3.org
> To: Newcomer, Eric; Thompson, Bryan B.; He, Hao; Michael Champion
> Cc: www-ws-arch@w3.org
> Sent: 2/14/2004 1:00 PM
> Subject: RE: non-outcry over eBay SOAP interace
> 
> 
> Wow!  That was great, Eric.
> 
> -----Original Message-----
> From: Newcomer, Eric [mailto:Eric.Newcomer@iona.com] 
> Sent: Saturday, February 14, 2004 8:05 AM
> To: Thompson, Bryan B.; He, Hao; Michael Champion; Cutler, Roger
> (RogerCutler)
> Cc: www-ws-arch@w3.org
> Subject: RE: non-outcry over eBay SOAP interace
> 
> 
> In the early days, when SOAP first came out, Henryk Neilsen 
> always described it as an "extension to HTTP."
> 
> if you look at the HTTP spec, you can see that it was 
> designed to be extended, even for things such as custom 
> interfaces, and SOAP is in practice what the industry has 
> settled upon as that extension.  When SOAP came out there 
> were many, many other proposals for XML protocols, that's why 
> the W3C WG is called XML P, not SOAP.  When the WG started 
> the first item of business was to develop requirements 
> against which to evaluate all the candidate XMLPs.  Some of 
> them are listed here:
> 
> http://www.w3.org/2000/03/29-XML-protocol-matrix
> 
> This debate reminds me a lot of the synch/asynch debate.  
> Once RPC was invented and became widely adopted, why would 
> anyone want to struggle with all the additional programming 
> overhead and complex error recovery inherent in asyhcnronous 
> communications protocols?  And for transaction processing, 
> why incur the overhead of three distinct transactions in 
> order to guarantee atomicity when with synchronous protocols 
> you could use just one?
> 
> At the X/Open (now Open Group) TP committee, best known for 
> producing XA, the messaging guys used to argue that 
> asynchronous messaging was the only thing you needed for the 
> Internet.  And they had a lot of good reasons, too, such as 
> eliminating the overhead of sessions necessary for 
> synchronous protocols and the relative ease of bridging 
> disparate systems (both architecturally and over time and space).
> 
> In the end I decided we were both right, and that the world 
> is divided up in some proportion between synchronous and 
> asynchronous communications, because some application 
> requirements are better served by one or the other.
> 
> It's also a lot like the CORBA/Web services debate.  Lots of 
> folks get lost in the details of technology comparisons and 
> easily conclude that CORBA is superior.  But for what 
> purpose?  Often in these discussions the human factor, what 
> people want to do with the technology, is omitted and the 
> debates become endless.
> 
> Here I think most folks have sensibly come to the conclusion 
> that the world is big enough for both SOAP and "REST" - 
> depending, of course, on what you want to do.  This was 
> Amazon.com's view, which you can hear on IT Conversations:
> 
> http://www.itconversations.com/detail.php?id=31
> 
> Some applications are better served using the plain XML over 
> HTTP; others by using the SOAP extensions.
> 
> I realize that software remains a very personal thing.  The 
> industry is not yet standardized the way other industries 
> are.  There's no one way of doing anything.  So of course we 
> are going to get individuals with strong opinions, who have 
> worked their own way through the various technologies and 
> settled upon what they think is best.  Unfortunately, the 
> arguments among such individuals can never be won, since by 
> definition they are personal views and inherently differ.
> 
> For whatever it's worth ;-)
> 
> Eric
> 
> 
> 
> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Thompson, Bryan B.
> Sent: Friday, February 13, 2004 6:38 AM
> To: He, Hao; 'Michael Champion'; Cutler, Roger (RogerCutler)
> Cc: www-ws-arch@w3.org
> Subject: RE: non-outcry over eBay SOAP interace
> 
> 
> 
> See: 
> http://lists.w3.org/Archives/Public/xml-dist-app/2002Mar/0056.html
> 
> in which Mark Baker argues in favor of SOAP for: "We *need* mandatory 
> extensions, header targetting, and a better documented 
> end-to-end model. Right now, SOAP is the only _deployed_ 
> means of getting all that."
> 
> However, this is in no small measure to the abortive attempt 
> at HTTP-NG, which did not gain a sufficient audience at the 
> IETF.  He also recently pointed me to a W3C Note that 
> provides an extension mechansim for HTTP.
> 
> See 
> http://www.w3.org/Protocols/HTTP/ietf-http-ext/draft-frystyk-h
> ttp-extens
> ions
> -03.txt
> and ftp://ftp.isi.edu/in-notes/rfc2774.txt, which seems to be 
> the most current draft (RFC 2774).
> 
> In sort, we can do these things within HTTP, and the existing 
> web, if we build the right contracts into the protocol or 
> into protocol extensions. Not everyone interested in REST 
> wants to use HTTP, but some of us are looking to extend the 
> current web architecture, so that means HTTP + requirements 
> such as those that Mark (and others) have outlined and 
> agreements on how those requirements will be fulfilled.
> 
> -bryan
> 
> 
> -----Original Message-----
> From: www-ws-arch-request@w3.org 
> [mailto:www-ws-arch-request@w3.org] On Behalf Of He, Hao
> 
> Sent: Thursday, February 12, 2004 4:17 PM
> To: 'Michael Champion'; Cutler, Roger (RogerCutler)
> Cc: www-ws-arch@w3.org
> Subject: RE: non-outcry over eBay SOAP interace
> 
> 
> Roger, 
> 
> Any idea why you "need the encapsulation of SOAP when 
> performing operations with a high level of contractual 
> commitment."? I cannot see the correlation here?
> 
> Hao
> 
> -----Original Message-----
> From: Michael Champion [mailto:mc@xegesis.org]
> Sent: Friday, 13 February 2004 8:08
> To: Cutler, Roger (RogerCutler)
> Cc: www-ws-arch@w3.org
> Subject: Re: non-outcry over eBay SOAP interace
> 
> 
> 
> 
> On Feb 12, 2004, at 4:01 PM, Cutler, Roger (RogerCutler) wrote:
> 
> > If you dig into the links a bit you find the following, 
> which I like:
> >
> > So there you have it in a nutshell. The XML-over-HTTP 
> openness of REST 
> > works best when you want to reach as wide a universe as 
> possible. On 
> > the other hand, you're going to need the encapsulation of SOAP when 
> > performing operations with a high level of contractual commitment.
> Most
> > applications will need to use some of each.
> >
> >
> I like that too.. where was it?
> 
> 
>

Received on Saturday, 14 February 2004 15:17:07 UTC