Re: proposal for restricting a service to a single interface

Sergey,

I looked at [1] and your <reference> proposal is structurally very similar 
to the <endpoint> proposal. In your proposal the @wsdl specifies a 
binding:

<portType name="InformationQueryPortType">
  <operation name="getToolkits">
    <output message="tns:getToolkitsResponse">
      <!-- part attribute is optional when a message has only one part -->
      <reference part="toolkits" portType="ToolkitPortType" 
                        xpath="q:Toolkits/q:Toolkit/@wsdl"/>
      <!-- possibly some more references to other port types in this 
output, within the same part or other parts -->
    </output>
  </operation>
</portType> 

Your use of xpath is the same, but in the <endpoint> proposal, the binding 
info is defered to the <binding> element and is declared statically in the 
WSDL document.

Concerning relative URIs, I suggest that XML Base [2] be used. I'll start 
a separate thread on that.

[1] http://www.zandar.com/webservices/articles/SessionWebServices.htm
[2] http://www.w3.org/TR/xmlbase/

Arthur Ryman,
WebSphere Studio Development Lead,
Web Services, XML and Data Tools

phone: 905-413-3077, TL 969-3077
assistant: 905-413-2323, TL 969-2323
fax: 905-413-4920, TL 969-4920
intranet: http://w3.torolab.ibm.com/~ryman/




"Sergey Beryozkin" <sberyozkin@zandar.com>
Sent by: www-ws-desc-request@w3.org
04/29/2003 12:20 PM

 
        To:     Arthur Ryman/Toronto/IBM@IBMCA
        cc:     "Amelia A. Lewis" <alewis@tibco.com>, "WS-Desc \(\(Public\)\)" 
<www-ws-desc@w3.org>
        Subject:        Re: proposal for restricting a service to a single interface

 


Arthur,

please have a look at
http://www.zandar.com/webservices/articles/SessionWebServices.htm (I wrote
it back in November 2002), the relevant part is "Time to REST" section at
the bottom of the article, where I was trying to put some suggestions
regarding R085 resolution (using Simon Fell's registration service as an
example, thanks).  It took me some time this morning to understand what I
was trying to say there :-); the idea was that to discover a binding
dynamically at runtime for a given endpoint an extra @wsdl attribute was
required, and it was that @wsdl attribute that was located through an 
xpath
selector. xlink:href which is used across the service is relative, and as
such there was an assumption that the runtime knows that it must append
xlink:href's value to the endpoint'sURI of the referencing service, and 
use
GET (or whatever the dynamically discovered binding says) on a new URI.
Also instead of specifying and locating @wsdl attribute (it's xlink:href
which must be located and @binding attribute, if required, be used instead 
,
as shown in the proposal [1]), issuing HTTP OPTIONS [2] on the new URI 
could
theoretically get the binding as well, thus making the binding discovery
process completely automatic, it may not be practical though.
By the way, are relative URIs (as the values of xlink:href) are allowed in
the proposal [1] ?

Thank you
Sergey Beryozkin,
Zandar Technologies, Dublin, Ireland

[1]
http://lists.w3.org/Archives/Public/www-ws-desc/2003Apr/att-0088/R085-2003-0
4-22.html
[2] http://lists.w3.org/Archives/Public/www-ws-desc/2002Nov/0006.html



Sergey,

> But what if each part contains multiple endpoints itself ? <p:Part>, for
> example, might not only contain a specification URI, but also have a 
list
> of vendor' URIs, etc.

If the message contains multiple endpoints of different interface types,
then you use a <endpoint> for each. The <endpoint> element is a child of
<input>, <output> or <fault> and can appear many times within each.
e.g.
<input>
        <endpoint name="partUri" interface="tns:PartInterface" ..../>
        <endpoint name="specUri" interface="tns:SpecInterface" .../>
</input>

Arthur Ryman,