Action 2005-04-22 Alternate Proposal for Service References

I took an action item to write a counter proposal based on our
discussion at the f2f meeting for service references, which is to
address the solution to the problem posted as  LC117[1]. 

Background: 

We have decided to use WSDL Service type as the basis for designating
service references. Our approach was to use restriction to indicate the
interface and/or binding at design time by using the type as basis.
However, as Arthur found out, this approach is not useable when bindings
need to be indicated as part of the reference due to XML Schema
restrictions as stated by LC 117[1]. 

As a result, the wg has decided to use Service Type as the basis when
Interface of the reference is known at design time and EndpointType as
the basis when the binding is known [2]. This design is reflected in the
Primer examples as well [3]. 

This is a counter proposal. 

Justification: 

As a person who has worked on the original proposal and the approach
that got integrated to the specification, I believe that reconsidering
the approach is necessary. This is due to following obvious drawbacks of
the current solution to LC 117 as decided by the wg in [2]. 

(a) The service can not be designed with approach in mind, one needs to
choose between Service Type or Endpoint Type depending on the
circumstances. It is confusing for the users of WSDL and XML Schema
since when to use the approprite type to designate a service reference
is conditional and the solution is not uniform. The reader can just see
this looking at our Primer section to recognize how a description needs
to use derivations from two separate types to see this complexity in
action (Refer to Section 7) I encourage the wg to read this section to
see the complexity we are introducing. (Arthur, you did an excellent job
in providing the examples in reflecting the decisions which were very
illustrative)

(b) There is new information. When we started exploring how to represent
service references, WS-Addressing wg had not been formed. Endpoint
References are defined by WS-Addressing working group that indicate
references to endpoints and they can  contain metadata. The metadata in
EPR allows EPRs to indicate alternate bindings and addresses for the
endpoint since WSDL description may be included in the EPR. 

Further, WS-Addressing is tackling bindings for both WSDL 1.1 and WSDL
2.0. As a result, it is more likely that WS messages will contain EPRs
within the content of the messages instead of using WSDL 2.0 specific
Service Type as WS-Addressing becomes more integrated, the EPR type will
be widely recognized and used by WS enabled software stacks. 

I recognize that EPR is considered more of a "runtime" construct. This
proposal does not contradict this assumption. Messages, however, will
contain EPRs and the need for descriptions to designate the interface
(and binding) of the reference staticly has not changed. Roberto's
writeup from September 2003 has already discussed the requirements in
this space [3] and the proposal below is similar to the approach (7)
described in that document. However, I even  simplified it further. 

The approach I have taken can be used both by WSDL 2.0 and WSDL 1.1
descriptions, akin to our wsdli:wsdlLocation element. Those of you who
are familiar with the Media Types note [6] would recognize the
similarities in this proposal. 

Details: 

This proposal consists of two separate parts:

(a) An Extension for WSDL 2.0 that helps identify references. 

I propose we remove Section 2.14.2.1 Service References (Core). 

Instead, I propose we add the following to Part 2 instead: 

Section XX: Predefined Extensions
XX.1 wsdlx:reference Attribute Information Item

WSDL 2.0 provides a global attribute information item with the following
Infoset properties

*	A [local name] of reference
*	A [namespace name] of "TBD" (we need a new namespace) ( Note: I
proposed earlier within the context of a different Action item such a
namespace [5])

The type of the wsdlx:reference attribute information item is a list of
xs:QName. 
The list may contain at most two xs:QName values. Its actual value
designates the QName which corresponds to the name of a WSDL interface
and the second QName which corresponds the name of the WSDL binding
respectively. 

The global attribute MAY be used by descriptions to indicate references
to endpoints in conjunction with elements that designate a reference
that contains an address to a Web Service. For example, WS-Addressing
defines Endpoint References that may be used by descriptions to refer to
endpoints. Messages that may include EPRs should use wsdx:reference
global attribute in their schema to refer to the interface (and binding)
of the WSDL service that they refer to. Depending on whether the
descriptions require staticly defining the values of interface name (or
both the interface and the binding names) of the referred endpoint at
description time, the actual value of the attribute may include one or
two xs:QNames. 

In order to resolve the QNames of the referred endpoint, the description
must include and/or import the corresponding WSDL components and the
corresponding components must be present in the component model. 

(Note: Alternatively, we can allow or require using wsdli:wsdlLocation
but I prefer making the requirement that all referred WSDL components
are actually present in the component model. This is because interaction
with wsdli:wsdlLocation attribute within a description is harder to
formulate rather than requiring the referred components to be
included/imported to the component model) 

The global attribute may be used in conjunction with WS-Addressing EPR
elements or URI elements. 
(Note: We may decide to allow types EPR or URI and types that are
derived from these types similar to the approach that media-type note
has taken if needed). 

(b) A Change to the Primer section that describe using service
references: 

The primer  will need to be changed considerably. To illustrate the
point, I will show how the proposal changes the example for Service
References in the Example. Refer to Section [4] for the set of examples.

We do not need the ReservationDetailsSOAPEndpointType and all the
complicated derivations that entail. The whole purpose is to fix the
interface and binding via deriving from wsdl:endpoint type. The
reservationDetailsEndpoint element may use wsa:endpointReference type
directly in its definition and it does not need to be a global element
even in order to fix the interface and binding, etc: 
Current definitions are: 
<complexType name="ReservationDetailsSOAPEndpointType"> 
       <complexContent> 
              <restriction base="wsdl:EndpointType"> 
                  <attribute name="binding" type="QName" use="required"
fixed="wdetails:reservationDetailsSOAPBinding" /> 
              </restriction> 
        </complexContent> 
</complexType> 
<element name="reservationDetailsSOAPEndpoint"
type="tns:ReservationDetailsSOAPEndpointType"> 
     <annotation> 
         <documentation> This element contains a reference to the
Reservation Details Web Service SOAP Endpoint for this reservation. 
         </documentation> 
     </annotation> 
</element> 
As part of the reservation element the reference is passed around as
shown below: 
<element name="reservation"> 
      <annotation> 
        <documentation> A reservation contains the confirmation number,
check-in and check-out dates, and a reference to a Reservation Details
Web service. 
       </documentation> 
      </annotation> 
      <complexType> 
             <sequence> 
                   <element ref="details:confirmationNumber" />
                   <element ref="details:checkInDate" /> 
                   <element ref="details:checkOutDate" /> 
                    <element
ref="details:reservationDetailsSOAPEndpoint" /> 
               </sequence> 
        </complexType> 
</element> 
REPLACE ALL of the above by the following: 
<element name="reservation"> 
      <annotation> 
        <documentation> A reservation contains the confirmation number,
check-in and check-out dates, and a reference to a Reservation Details
Web service. 
       </documentation> 
      </annotation> 
      <complexType> 
             <sequence> 
                   <element ref="details:confirmationNumber" />
                   <element ref="details:checkInDate" /> 
                   <element ref="details:checkOutDate" /> 
                    <element ref="wsa:EndpointReference" 
 
wsdx:reference="wdetails:reservationDetailsInterface
wdetails:reservationDetailsSOAPBinding" /> 
               </sequence> 
        </complexType> 
</element> 
References: 
[1] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC117
[2]
http://lists.w3.org/Archives/Public/www-ws-desc/2005Apr/att-0162/2005042
2-ws-desc-minutes.html

[3]
http://lists.w3.org/Archives/Public/www-ws-desc/2003Oct/att-0345/counter
proposal.html

[4]
http://www.w3.org/TR/2005/WD-wsdl20-primer-20050510/#adv-service-referen
ces

[5] http://lists.w3.org/Archives/Public/www-ws-desc/2005May/0059.html

[6] http://www.w3.org/TR/xml-media-types/