RE: Proposed issue; Visibility of Web services

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