Re: Proposed issue; Visibility of Web services

The problem I was trying to solve was to make a constructive proof that 
the visibility of SOAP (over GET or over POST, either way) was the same 
as the visibility as GET with parameters. What matters to the proof is 
that there exists some such encoding; the one that you created will do 
as well as any other.

More interesting is the point that Allan just made. Prescod actually 
says that we can "make a businessEntity an XML document addressable at a 
URI like"http://www.uddi.org/businessEntity/ibm.com" or perhaps 
"http://www.uddi.org/getbusinessEntity?ibm.com". The difference between 
these two is subtle and does not have many technical implications so 
let's not worry about it."

But let's do worry about it, because there is a real difference in 
visibility here. We can show that there cannot be a 1-1 correspondence 
between things of these two forms by arguing as follows. For any set of 
things of the first form (the "?"-free form) that you give me, I can 
construct a bigger set of things of the second form.
Here's one fairly stupid way to do that. Say you give me these n = 2 
things of the first form:

http://www.uddi.org/businessEntity/ibm.com
http://www.uddi.org/businessEntity/bea.com

Then I will give you back these things 2**n - 1 = 3 things of the second 
form:

http://www.uddi.org/getbusinessEntity?ibm.com
http://www.uddi.org/getbusinessEntity?bea.com
http://www.uddi.org/getbusinessEntity?ibm.com&bea.com

Of course there are really a whole lot more things of the econd form. 
Intuitivily, it seems that the second form is free -- the requestor can 
supply anything she wants for the variable part, including, you know, 
the secret key to the trapdoor, or whatever -- while the first form is 
bound.

Jeff


David Orchard wrote:

> Jeff,
>  
> I created such a thing about a year ago [1].  This doesn't really 
> solve the problem that is at the heart of the propose issue, which is 
> the heavy use that SOAP applications make of bindings to HTTP POST 
> instead of GET.  Some people think that POST should be avoided because 
> it requires specific configuration, ie the Xpath expression, for what 
> to look for in a message instead of simply the HTTP method and URI.  
> It's really a question of scale of visibility versus simplicity across 
> multiple protocols and applications.
>  
> Cheers,
> Dave
>  
> [1] http://www.w3.org/2001/tag/doc/ws-uri.html
>
>     -----Original Message-----
>     From: www-ws-request@w3.org [mailto:www-ws-request@w3.org]On
>     Behalf Of Jeff Lansing
>     Sent: Friday, May 30, 2003 11:55 AM
>     To: www-ws@w3.org
>     Subject: Re: Proposed issue; Visibility of Web services
>
>     Hi,
>
>     There was a long discussion about the relative "visibility" of
>     HTTP vs SOAP. There seemed to be a tendency to believe that HTTP
>     GET was the most "visible" of all.
>
>     Now any SOAP message can be encoded as a HTTP GET, with "?" and "&"s.
>
>     Here's one way. Make XPath expressions for all the content in the
>     SOAP message, for example:
>
>     soap:Envelope/soap:Body/m:GetStockPrice/m:StockName
>
>     URL encode these expressions (not shown here). Then make a parameter:
>
>     soap:Envelope/soap:Body/m:GetStockPrice/m:StockName=IBM
>
>     Then string all the parameters together with ampersands.
>
>     This (with a few more tricks for namespace definitions and
>     attributes) is a linear encoding of all of the information in the
>     SOAP message into a GET request. No more and no less. So how can
>     it be claimed that there is a difference in "visibility" between
>     the two?
>
>     Jeff
>
>
>     Mark Baker wrote:
>
>>On Thu, May 29, 2003 at 12:28:46PM -0400, Christopher B Ferris wrote:
>>  
>>
>>>I guess I just don't know what you think a "generic" intermediary is then. 
>>>Give me an example
>>>of a generic HTTP intermediary that does not have a specific role(s) like 
>>>caching.  If my cache example
>>>is not generic, I don't know what is. You seemed to have simply ignored 
>>>that aspect of
>>>my previous message. Was my example not "generic" by your standards?
>>>    
>>>
>>
>>No, at least not for the purposes of doing the apples-to-apples
>>visibility comparison.  I was trying to emphasize that HTTP defines
>>many application layer features, while SOAP does not.  That may seem
>>obvious and non-important, because SOAP may have lots in the future, but
>>that's really the point; it doesn't have them now, so a SOAP
>>intermediary developed with no knowledge of them has no visibility into
>>a transaction that uses them (outside of knowing that it doesn't know
>>what they mean, ala mustUnderstand).
>>
>>Mike has said that SOAP firewalls will be going to market soon.  What
>>SOAP applications will they understand?  Will those firewalls be
>>upgraded for every new extension that comes along?  Because that's the
>>only way will they have similar visibility into SOAP transactions that
>>HTTP intermediaries developed today will have into HTTP transactions
>>executed 10 years from now.
>>
>>BTW, I would *really* appreciate a response to this;
>>
>>  
>>
>>>>A SOAP+E intermediary would have *excellent* visibility into an
>>>>interaction between a client and server using those extensions, right?.
>>>>For example, if it had hardcoded-in knowledge of WS-Transaction, then it
>>>>could sit between a client and server coordinating a transaction, and
>>>>be able to follow along quite well; far better than it could if
>>>>something other than a transaction was being coordinated.  Agreed?
>>>>
>>>>So can you see my point?  HTTP is at the same layer as WS-Transaction;
>>>>both are application layer coordination languages.
>>>>      
>>>>
>>
>>MB
>>  
>>
>