- From: Umit Yalcinalp <umit.yalcinalp@oracle.com>
- Date: Wed, 05 Nov 2003 10:53:16 -0800
- To: WS Description List <www-ws-desc@w3.org>
- Message-ID: <3FA9471C.7030600@oracle.com>
I think it is healty to present this to this group. I believe that late
binding of "binding "information can not be addressed appropriately with
our (IBM, Oracle, Sonic) previous proposal either that we presented in
the last f2f. This is my response to Roberto's proposal [2] which I
originally sent to Roberto, Glen and Arthur and I would like to presend
in light of Arthur's objections [3]. I don't believe using the
wsdl:reference element is the best solution either, but has its uses for
assigning a single binding information to a reference when WSDL is built
in stages and binding is assigned later on during the development to a
service reference.
This is a reconciliation proposal that I think will accomodate
everybody. I copy it verbatim.
--umit
[2] http://lists.w3.org/Archives/Public/www-ws-desc/2003Oct/0345.html
[3] http://lists.w3.org/Archives/Public/www-ws-desc/2003Nov/0041.html
-------------------------------------------------------------------
We have three cases that we need to support for web service references:
(1) fully static (interface and binding are known)
(2) semi static (interface is known)
(3) dynamic (nothing is known about the reference, except the fact that
the message contains a reference).
-- WSDL designates a reference type for designating a service reference.
There are two base types that are covered by WSDL:
(a) wsdl:Service. This type and all types derived from it is applicable
and recognized as a reference type.
(b) xsd:anyURI.
(c) Any other type.
Roberto/Glen proposal introduces the following attributes three
attributes in wsdlx namespace. (now where is my repository so that I
can pinpoint to the proposal by a reference :-))
a1. <xs:attribute name="interface" type="xs:QName" use="required"/>
a2. <xs:attribute name="binding" type="xs:QName" use="required"/>
a3. <xs:attribute name="serviceReference" use="required" fixed="true"/>
P1. I propose that we use only the wsdl namespace for defining
new types/attributes. This is not an extension.
P2. I propose we eliminate a3 as it is not required at all. If
we have a type derived from (a-c) and they either use the
attributes (a1-a2) which designates the type to be a
reference, or they don't. The presence of the other
indicators, such as declaration of interface and/or binding
tells us that they are a reference. For wsdl:Service type
derivations, I don't understand the value of it and I propose
we omit it.
P3. I propose WSDL to adopt a global "interface" attribute in
sync with Roberto/Glen proposal. Here is my reasoning.
We have three cases, 1-3,
b. xs:anyURI derivations. This can be used only with case 1.
We require that each a new type is derived from the interface anyway. (IBM/Oracle proposal) [1] as follows
<xs:simpleType name="ManagerReference">
<xs:restriction type="xs:anyURI"/>
</xs:simpleType>
the number of additional schema types is equivalent to the number of referenced interfaces and bindings.
This is also true with the Roberto/Glen approach:
<xs:complexType name="ManagerReference">
<xs:simpleContent>
<xs:extension base="xsd:anyURI">
<xs:attribute name="interface" type="tns:ManagerInterface"
use="required"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType>
This does not bother me, because at the abstract level of WSDL you
need to define a separate schema type for each type. From this
perspective, whether you define this separately as we proposed in [1]
or as in the new proposal does not matter. You end up having exactly
the same number of new derived types for each interface. Further, my
argument is that even if one may be designing their WSDL in several
stages, first abstract types, and then binding, then endpoint
addresses for deployment, designing the WSDL and the data types belong
to the same stage in development.
From the schema processors point of view, there are additional derived
types to deal with. I can see one particular advantage with the
Roberto/Glen proposal. This is because a special hint for PSVI step is
present in the schema with the presence of this attribute and its
value. This is not true in our proposal [1]. I consider this
equivalent to having a schema annotation. However, we should also propose
the following change to WSDL schema:
P4: The current WSDL schema should be changed to use the
attribute defined by P3 in the defn of wsdl:Service type. In
this manner, the attribute defn is used consistently
everywhere.
a. wsdl:Service: As I am lead to believe that we need to specify this
with a restriction. Yet Roberto/Glen proposal is by schema
extension. I think this is a typo.
For each type of reference indicated by the interface of the service
and there needs to be a one-to-one mapping. With P4, wsdl:Service type
can further restrict the type as a fixed value. I really like this
because we use full facility of the schema. Further, P4 allows reusing
the same attribute defn both for URIs and in wsdl:Service type.
Summary: I propose that we utilize the global attribute declarations
which should be part of the wsdl schema as part of declaring the
interface with P1-P4.
Contentious Issue: Declaration of the binding. (a2) !!!
Roberto/Glen propose that we do this by using the attribute a2. In
[1], we have used wsdl:reference element to do exactly the same thing.
Arthur argues that it is not a great idea to combine the binding
information in the schema as binding can be declared independent of
the abstract level development (Arthur don't want to represent you
incorrectly, but this is my assessment).
Arthur has one valid point. For example, if I develop my abstract
layer in WSDL using the techniques described above, I will be ending
up with
<xs:simpleType name="ClaimsDeptReference">
<xs:restriction type="xs:anyURI"/>
</xs:simpleType>
<interface name="PatientRecords">
<operation name="findPatientsClaimDept" pattern="...">
<input messageReference=".." body="tns:patientClaimsInquiry"/>
<output messageReference=".." body="tns:ClaimsDeptReference"/>
</operation>
</interface>
in my schema, and some other party who declares the binding can assign
the binding of choice later in the binding section of WSDL by using
wsdl:reference element.
However, I observe that this only works when you know in advance that
you will always have one binding, not more. This is because the
reference in the message can not be associated with more than one
binding in the fully static case (1). This is a problem for URI
derived types, because I can not assign two different bindings,
i.e. SMTP and SOAP/HTTP binding to the same interface at the same
time. One schema type is the placeholder for one binding, nothing more
nothing less. As a result, I will have to do the following:
<xs:simpleType name="ClaimsDeptReference">
<xs:restriction type="xs:anyURI"/>
</xs:simpleType>
<xs:simpleType name="ClaimsDeptEmailReference">
<xs:restriction type="xs:anyURI"/>
</xs:simpleType>
<interface name="PatientRecords">
<operation name="findPatientsClaimDept">
<input messageR.. body="tns:patientClaimsInquiry"/>
<output message body="tns:ClaimsDeptReference"/>
</operation>
<operation name="findPatientsClaimDeptForEmail">
<input messageR.. body="tns:patientClaimsInquiry"/>
<output message body="tns:ClaimsDeptEmailReference"/>
</operation>
</interface>
(I know that this modification is against what I proposed with R2004
as the same input element is used with two different operations, but
lets forget this for a moment as it is not relevant for this
discussion. :-))
The binding for operations, findPatientsClaimDept and
findPatientsClaimDeptForEmail will have two different wsdl:reference
elements, first for tns:ClaimsDeptEmailReference and the other for
tns:ClaimsDeptReference.
At the abstract layer I had to modify my interface and add schema
types to accomodate this case.
This is NOT different than what Roberto/Glen is proposing, because in
that case, an interface and the binding will be part of the schema and
you will end up with the same number of schema types.
So regardless of what we do in associating the binding with the type,
we end up with the same number of types and further the interface
needs to be modified. Note that this is true for problem (1) and using type
(b). When we use type (a) wsdl:Service, we don't have to modify the
interface, we can omit the declaration of the binding altogether and
it works.
One argument in favor of leaving wsdl:reference declarations is that
the case I am presenting may not be too common, and folks who will use
URIs care about HTTP binding only. Even if this is the case, I am in
favor of reuse. So having said all this, I came to the conclusion that
we should allow both methodologies with the following modifications:
P5: We introduce the global attribute a2 into the WSDL
schema. (This is not global right now, but used in the schema
in a local declaration). We also change the defn of
wsdl:Service type to use this new attribute.
P6: We change the definition of wsdl:reference to utilize P5.
<wsdl:reference type="xs:Qname" wsdl:binding=.../>. This
element is allowed to be used with reference to types other than
wsdl:Service.
P7: WSDL/Schema authors are allowed to use wsdl:binding
attribute in their schema to annotate the binding that they
require. (per Roberto/Glen proposal).
The caveat is of course you can use either P6 or P7, but not both.
Arthur, I know you are in favor of declaring everything in wsdl but I
believe this solution addresses your concern. Roberto/Glen i am well
aware that you would like to solve the problem entirely in Schema,
however this approach namely P5-P6, solves the problem of adding
binding information when WSDL is not developed in its entirety. I know
that you guys prefer an option where wsdl:reference elements were
completely removed, but this will cover the cases that I believe
Arthur is concerned about.
None of the approaches are clean, as they all require introducing
additional types as there are interface+binding pairs as far as static
definition of references are concerned. I observe that wsdl:Service
type does not have this problem. Again, for the sake of addressing the
needs of URI/REST community, I am comfortable with this compramise.
If all of us agree with points, except P6, I request thinking
through whether you could live with a not-to-perfect-but-ok solution
from your perspectives and let me know what you think. I fear that
otherwise we will end up having no solution in WSDL 2.0 for
references, which is a bad idea.
I can live with P6 and/or P7. I note again that this will be only
necessary for URI (and perhaps other types), but not wsdl:Service. So
it is optional.
I will not be in favor of any solution which does not include wsdl:Service.
If you have noted, I am in favor of NOT introducing a derived type
from wsdl:Service, and/or anyURI. This is because of my views in
P2. Frankly, I also think that it will get more resistence from the
wg.
[1] http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/att-0187/example3a-1.txt
-------------------------------------------------------------------
We have three cases that we need to support for web service references:
(1) fully static (interface and binding are known)
(2) semi static (interface is known)
(3) dynamic (nothing is known about the reference, except the fact that
the message contains a reference).
-- WSDL designates a reference type for designating a service reference.
There are two base types that are covered by WSDL:
(a) wsdl:Service. This type and all types derived from it is applicable
and recognized as a reference type.
(b) xsd:anyURI.
(c) Any other type.
Roberto/Glen proposal introduces the following attributes three
attributes in wsdlx namespace. (now where is my repository so that I
can pinpoint to the proposal by a reference :-))
a1. <xs:attribute name="interface" type="xs:QName" use="required"/>
a2. <xs:attribute name="binding" type="xs:QName" use="required"/>
a3. <xs:attribute name="serviceReference" use="required" fixed="true"/>
P1. I propose that we use only the wsdl namespace for defining
new types/attributes. This is not an extension.
P2. I propose we eliminate a3 as it is not required at all. If
we have a type derived from (a-c) and they either use the
attributes (a1-a2) which designates the type to be a
reference, or they don't. The presence of the other
indicators, such as declaration of interface and/or binding
tells us that they are a reference. For wsdl:Service type
derivations, I don't understand the value of it and I propose
we omit it.
P3. I propose WSDL to adopt a global "interface" attribute in
sync with Roberto/Glen proposal. Here is my reasoning.
We have three cases, 1-3,
b. xs:anyURI derivations. This can be used only with case 1.
We require that each a new type is derived from the interface anyway. (IBM/Oracle proposal) [1] as follows
<xs:simpleType name="ManagerReference">
<xs:restriction type="xs:anyURI"/>
</xs:simpleType>
the number of additional schema types is equivalent to the number of referenced interfaces and bindings.
This is also true with the Roberto/Glen approach:
<xs:complexType name="ManagerReference">
<xs:simpleContent>
<xs:extension base="xsd:anyURI">
<xs:attribute name="interface" type="tns:ManagerInterface"
use="required"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType>
This does not bother me, because at the abstract level of WSDL you
need to define a separate schema type for each type. From this
perspective, whether you define this separately as we proposed in [1]
or as in the new proposal does not matter. You end up having exactly
the same number of new derived types for each interface. Further, my
argument is that even if one may be designing their WSDL in several
stages, first abstract types, and then binding, then endpoint
addresses for deployment, designing the WSDL and the data types belong
to the same stage in development.
From the schema processors point of view, there are additional derived
types to deal with. I can see one particular advantage with the
Roberto/Glen proposal. This is because a special hint for PSVI step is
present in the schema with the presence of this attribute and its
value. This is not true in our proposal [1]. I consider this
equivalent to having a schema annotation. However, we should also propose
the following change to WSDL schema:
P4: The current WSDL schema should be changed to use the
attribute defined by P3 in the defn of wsdl:Service type. In
this manner, the attribute defn is used consistently
everywhere.
a. wsdl:Service: As I am lead to believe that we need to specify this
with a restriction. Yet Roberto/Glen proposal is by schema
extension. I think this is a typo.
For each type of reference indicated by the interface of the service
and there needs to be a one-to-one mapping. With P4, wsdl:Service type
can further restrict the type as a fixed value. I really like this
because we use full facility of the schema. Further, P4 allows reusing
the same attribute defn both for URIs and in wsdl:Service type.
Summary: I propose that we utilize the global attribute declarations
which should be part of the wsdl schema as part of declaring the
interface with P1-P4.
Contentious Issue: Declaration of the binding. (a2) !!!
Roberto/Glen propose that we do this by using the attribute a2. In
[1], we have used wsdl:reference element to do exactly the same thing.
Arthur argues that it is not a great idea to combine the binding
information in the schema as binding can be declared independent of
the abstract level development (Arthur don't want to represent you
incorrectly, but this is my assessment).
Arthur has one valid point. For example, if I develop my abstract
layer in WSDL using the techniques described above, I will be ending
up with
<xs:simpleType name="ClaimsDeptReference">
<xs:restriction type="xs:anyURI"/>
</xs:simpleType>
<interface name="PatientRecords">
<operation name="findPatientsClaimDept" pattern="...">
<input messageReference=".." body="tns:patientClaimsInquiry"/>
<output messageReference=".." body="tns:ClaimsDeptReference"/>
</operation>
</interface>
in my schema, and some other party who declares the binding can assign
the binding of choice later in the binding section of WSDL by using
wsdl:reference element.
However, I observe that this only works when you know in advance that
you will always have one binding, not more. This is because the
reference in the message can not be associated with more than one
binding in the fully static case (1). This is a problem for URI
derived types, because I can not assign two different bindings,
i.e. SMTP and SOAP/HTTP binding to the same interface at the same
time. One schema type is the placeholder for one binding, nothing more
nothing less. As a result, I will have to do the following:
<xs:simpleType name="ClaimsDeptReference">
<xs:restriction type="xs:anyURI"/>
</xs:simpleType>
<xs:simpleType name="ClaimsDeptEmailReference">
<xs:restriction type="xs:anyURI"/>
</xs:simpleType>
<interface name="PatientRecords">
<operation name="findPatientsClaimDept">
<input messageR.. body="tns:patientClaimsInquiry"/>
<output message body="tns:ClaimsDeptReference"/>
</operation>
<operation name="findPatientsClaimDeptForEmail">
<input messageR.. body="tns:patientClaimsInquiry"/>
<output message body="tns:ClaimsDeptEmailReference"/>
</operation>
</interface>
(I know that this modification is against what I proposed with R2004
as the same input element is used with two different operations, but
lets forget this for a moment as it is not relevant for this
discussion. :-))
The binding for operations, findPatientsClaimDept and
findPatientsClaimDeptForEmail will have two different wsdl:reference
elements, first for tns:ClaimsDeptEmailReference and the other for
tns:ClaimsDeptReference.
At the abstract layer I had to modify my interface and add schema
types to accomodate this case.
This is NOT different than what Roberto/Glen is proposing, because in
that case, an interface and the binding will be part of the schema and
you will end up with the same number of schema types.
So regardless of what we do in associating the binding with the type,
we end up with the same number of types and further the interface
needs to be modified. Note that this is true for problem (1) and using type
(b). When we use type (a) wsdl:Service, we don't have to modify the
interface, we can omit the declaration of the binding altogether and
it works.
One argument in favor of leaving wsdl:reference declarations is that
the case I am presenting may not be too common, and folks who will use
URIs care about HTTP binding only. Even if this is the case, I am in
favor of reuse. So having said all this, I came to the conclusion that
we should allow both methodologies with the following modifications:
P5: We introduce the global attribute a2 into the WSDL
schema. (This is not global right now, but used in the schema
in a local declaration). We also change the defn of
wsdl:Service type to use this new attribute.
P6: We change the definition of wsdl:reference to utilize P5.
<wsdl:reference type="xs:Qname" wsdl:binding=.../>. This
element is allowed to be used with reference to types other than
wsdl:Service.
P7: WSDL/Schema authors are allowed to use wsdl:binding
attribute in their schema to annotate the binding that they
require. (per Roberto/Glen proposal).
The caveat is of course you can use either P6 or P7, but not both.
Arthur, I know you are in favor of declaring everything in wsdl but I
believe this solution addresses your concern. Roberto/Glen i am well
aware that you would like to solve the problem entirely in Schema,
however this approach namely P5-P6, solves the problem of adding
binding information when WSDL is not developed in its entirety. I know
that you guys prefer an option where wsdl:reference elements were
completely removed, but this will cover the cases that I believe
Arthur is concerned about.
None of the approaches are clean, as they all require introducing
additional types as there are interface+binding pairs as far as static
definition of references are concerned. I observe that wsdl:Service
type does not have this problem. Again, for the sake of addressing the
needs of URI/REST community, I am comfortable with this compramise.
If all of us agree with points, except P6, I request thinking
through whether you could live with a not-to-perfect-but-ok solution
from your perspectives and let me know what you think. I fear that
otherwise we will end up having no solution in WSDL 2.0 for
references, which is a bad idea.
I can live with P6 and/or P7. I note again that this will be only
necessary for URI (and perhaps other types), but not wsdl:Service. So
it is optional.
I will not be in favor of any solution which does not include wsdl:Service.
If you have noted, I am in favor of NOT introducing a derived type
from wsdl:Service, and/or anyURI. This is because of my views in
P2. Frankly, I also think that it will get more resistence from the
wg.
[1] http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/att-0187/example3a-1.txt
Received on Wednesday, 5 November 2003 13:56:15 UTC