


From: Sergey Beryozkin <sberyozkin@zandar.com>
Date: Wed, 7 May 2003 10:13:49 +0100
Message-ID: <007301c31478$f923f460$1800a8c0@BERYOZKIN>
To: "Arthur Ryman" <ryman@ca.ibm.com>
I spent some time yesterday trying to find a case for a dynamic binding discovery, as related to R085.
IMHO, there're two possible approaches :
1. The endpoint reference [1] returns an absolute URI handle (I'm borrowing the term from the Grid OGSA spec - can't get the link for some reasons, sorry), rather than an endpoint address. This means that the runtime needs to query it for a WSDL from which it can get an address and a binding. This bring more complexity on the client part. The advantage is that a resource can be made accessible at different endpoints over time; however, the same can be achieved with [1], where  the endpoint reference can return different addresses over time.
2. The endpoint reference [1] returns an address (might be relative), as defined by [1], but there's no statically available binding (if it's available, then the endpoint ref might indicate that another preferred binding is available), which means that the binding needs to be retrieved from the above address first.
It seems that both approaches are similar in that the binding can be changed at runtime. Possible cases are :
- the service provider has decided to move from SOAP doc/literal to HTTP POST (or vise versa), and wants a seamless transition to a new binding without updating the WSDL doc, etc
- the service provider is now supporting a binding to a portType/interface which extends the original interface and wants to deprecate the older binding definition
This is as far as I can get at this stage
Sergey Beryozkin

  ----- Original Message ----- 
  From: Arthur Ryman 
  To: Sergey Beryozkin 
  Sent: Monday, May 05, 2003 6:44 PM
  Subject: Re: Proposal for Describing Web Services that Refer to Other Web Services: R085


  You are defining a dynamic binding discovery protocol, which is  beyond the scope of R085. Recall that R085 is a WSDL requirement. It states that a WSDL document must describe the endpoint. If you feel that dynamic discovery is important, then I suggest you submit this to the WG as a new requirement, and give a good motivating example. IMHO, I think it is useful to dynamically retrieve the WSDL associated with an endpoint, not just retrieve the binding. 

  I see a small problem with your proposed implementation. You say that the binding is obtained by performing a retrieval on the URI of the endpoint. However, you can't retrieve the URI unless you know the binding. You have to assume some binding, e.g. if the URI uses http: then do a GET (possibly with something appended to the URI, e.g. ?WSDL).

  Arthur Ryman 

       "Sergey Beryozkin" <sberyozkin@zandar.com> 
        05/01/2003 11:48 AM 

                To:        Arthur Ryman/Toronto/IBM@IBMCA 



  I'd just like to return again to the question of whether dynamic bindings
  should be disallowed by the proposal[1]or not. Proposal [1] says @binding
  attribute is declared statically in the WSDL document, this probably covers
  the majority of cases.

  How practical/usefult would it be to add @binding optional attribute to the
  endpoint reference definition :

  <wsdl:endpoint name="partURI" part="return"
  xpath="/p:Parts/Part/@xlink:href" interface="tns:partInterface"

  @binding attribute can have 2 values, "static" (default) and "dynamic". When
  @binding is "dynamic", the runtime *may*, but has not to, try to retrieve a
  binding definition from the newly created URI (perhaps with an extra
  path/request parameter to indicate that it's not the representation which is
  If dynamic binding discovery is not attempted/fails, a binding statically
  referenced (as shown in [1]) will be used.
  If dynamic binding is used then a wsdl doc is returned. This returned wsdl
  must contain a binding for a given interface (probably identified the way
  shown in [1]), and may/should also contain a <service> element. One issue
  here is that the returned wsdl has to know about portTypes/interfaces
  referenced in the original wsdl doc, and a such, these portTypes must be
  grouped in a separate WSDL doc.

  Sergey Beryozkin

Received on Wednesday, 7 May 2003 05:13:39 GMT
