RE: Proposed issue; Visibility of Web services

UDDI V2 already defines the second form, in terms of a discoveryURL.  For
example, you can get IBM's XML document by issuing an HTTP GET using the URL
http://uddi.ibm.com/ubr/uddiget?businessKey=D2033110-3AAF-11D5-80DC-00203522
9C64

 

UDDI V3 generalised this to all the UDDI entities that have a key, not just
the businessEntity.  See [1].

 

In the particular case of UDDI the queries are constrained sufficiently that
there is not much difference between the two forms and I think there is a
1-1 correspondence.

 

1 http://uddi.org/pubs/uddi-v3.00-published-20020719.htm#_Toc42047357

 

John Colgrave

IBM

 

-----Original Message-----
From: www-ws-request@w3.org [mailto:www-ws-request@w3.org] On Behalf Of Jeff
Lansing
Sent: 30 May 2003 23:36
To: www-ws@w3.org
Subject: 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>
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