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
>  
>