Re: Agenda, 5 June 2003 WS Desc telcon

Arthur Ryman wrote:

>
> I have reviewed Umit's proposal for an alternate approach to R085 and 
> have the following comments.

Arthur,

Thanks for starting the discussion on this topic!.

>
> 1. Umit's proposal includes the case of dynamic Web services 
> references. This is the case where the type of reference is not known 
> at description time. The type information is sent along with the 
> endpoint URI. This is beyond the scope of R085, which addresses the 
> static case only, i.e. when the type of the service is known at design 
> time. Also, the solution Umit proposes is a duplication of the 
> WS-Addressing proposal [1]. The WG should decide how to handle the 
> proposal. I will therefore confine my further remarks to the R085 case.
>
> [1] http://www-106.ibm.com/developerworks/webservices/library/ws-add/ 


We have read R085. Actually, there is nowhere in the wording that 
indicates that the requirement is limited to the static case.

Oracle's position is that the definition of a web service reference must 
be applicable to both static and dynamic use cases. It is in our best 
interest to find a solution that can handle both. This is why we made 
the proposal.  Note that today the "only" way to uniquely identify the 
web service is the service element itself. That is in essence indicates 
the identity of the service which can be used as the basis of a reference.

Having said that, I would like to reiterate that my writeup [1] solves 
two related, but orthogonal problems:

(a) how to indicate the type of a web service reference (based on my 
action item). [2]
(b) how to define a structure which can be used both statically and 
dynamically.

The techniques presented in (a) are applicable for (b).


>
>
> 2. Umit's approach is motivated by a desire to "get rid of XPath" and 
> replace it with an approach based on XSD. I don't fully understand why 
> the WG thinks this is a good idea. XPath was specifically designed to 
> identify parts of an XML instance document and so it is directly 
> applicable to identify the position of endpoint URIs or other complex 
> types that contain addressing information. 

Let me make a clarification. During the f2f, we decided to explore 
 schema annotations to define typed URIs that would indicate a web 
service reference [2]. The reason for exploring that was not my personal 
motivation per se, but a desire expressed by most of the attendees at 
the f2f to see an alternate way of indicating the type of the interface 
for the URI.  Therefore, I came up with  three different ways of 
achieving the same goal, namely relating the URI and the reference's 
interface based on the discussion. XPath was already covered by your 
writeup and presentation. The discussion can also be found in [2].

The problem we are solving is based on the fact that by just having a 
URI at hand, you don't know what it is. If it is a reference for a web 
service, then somehow you need to designate what it's type is and where 
in your type system it occurs. There are at least four different ways of 
accomplishing this. You have listed 1 (XPath/SCD) [3], [4], I have 
provided 3 more.

>
>
> On the other hand, XSD was intended to define grammars for XML 
> vocabularies. XSD allows an XML parser to determine if the sequence of 
> characters that comprises a document is a valid instance with respect 
> to a schema, e.g. a parser can determine if a sequence of characters 
> is a valid URI as defined by the simple type xsd:anyURI. A parser has 
> no way of telling what that URI points to. XSD does allow application 
> specific information to be associated with parts of a schema by means 
> of the elements xsd:annotation and xsd:appInfo, but this is not a 
> widely used practice.
>
> Umit's preferred approach is to introduce a new simple type 
> wsdl:ws-reference-uri which is simply a wrapped version of xsd:anyURI. 
> All endpoint URI should derive from this and define a new wrapper type 
> for each WSDL interface that is referenced. Umit describes other 
> approaches which I will not discuss since this is her preferred approach. 

All approaches have their pros and cons. I do hope that the rest of the 
wg reads the analysis carefully as you do. To summarize, here is what we 
have besides XPath.

1. Type declaration and relationship declaration with wsdl:endpoint
2. Schema annotation
3. Paswa approach.

>
> For example, suppose a service returns a reference to a service that 
> implements the WSDL interface p:partInterface. In Umit's proposal we 
> have the standard WSDL definition:
>
> <xsd:simpleType name="ws-reference-uri">
>     <xsd:restriction base="xsd:anyURI"/>
> </xsd:simpleType>
>
> and the service specific definition
>
> <xsd:simpleType name="PartReference">
>     <xsd:restriction base="wsdl:ws-reference-uri">
> </xsd:simpleType>
>
> In my example, the endpoint reference interface definition is:
>
> <endpoint name="partURI" part="return" interface="tns:partInterface" 
> xpath="/p:Parts/Part/@reference"/>
>
> In Umit's proposal, the p:Part complex type is rewritten to use 
> p:PartReference and the endpoint definition becomes:
>
> <endpoint name="partURI" part="return" interface="tns:partInterface" 
> type="p:PartReference"/>
>
> 3. I'd now like to focus on the differences in these approaches.
>
> 3.1 XPath Approach
>
> In the XPath approach there is no coupling between XSD and WSDL. The 
> XSD can be written independently of the WSDL. In many organizations, 
> the XSD is written first and then used in WSDL. Often, the XSD and 
> WSDL are written by different individuals or departments. The XPath 
> approach allows standard XSD definitions to be reused in different Web 
> services. For example, a Person document could include a URI to a 
> Department. However, the Web service associated with the Department 
> might depend on the application, e.g. Human Resources, Real Estate, 
> Project Management.
>
> The XPath approach also allows the endpoint definition to be based on 
> instance data in the message. For example, suppose a Department 
> document contained a list of Person elements, each containing a job 
> code attribute ("manager" or "employee") and a URI to a Web service 
> for the Person. The following is possible with XPath but not XSD:
>
> <endpoint name="managerURI" part="return" 
> interface="tns:managerInterface" 
> xpath="/Department/Person[@jobCode='manager']"/>
> <endpoint name="employeeURI" part="return" 
> interface="tns:employeeInterface" 
> xpath="/Department/Person[@jobCode='employee']"/>
>
> which allows message instances like:
>
> <Department id="NEWS">
>     <Person 
> jobCode="manager">http://www.wjm-tv.com/people/LouGrant</Person>
>     <Person 
> jobCode="employee">http://www.wjm-tv.com/people/MaryRichards</Person>
>     <Person 
> jobCode="employee">http://www.wjm-tv.com/people/TedBaxter</Person>
> </Department>
>
> In this example, Lou Grant's URI implements the managerInterface, but 
> Mary Richards and Ted Baxter implement the employeeInterface.
>
> The ability to have interface depend on instance data seems very 
> powerful. Is it too powerful?
>
> The downside is that a WSDL author and processor must understand XPath 
> which is a further complication. However, XPath is a relatively simple 
> syntax and XPath processors are widely available. 

I would like to understand why you prefer XPath in contrast to SCDs. 
After all, XPath is at the instance level, but the WSDL is defined at 
the type level. However incomplete it would be, conceptually SCD is 
defined at the type level. So if a pointer based approach were to be 
used based on structural content, SCD appears to be more suitable for 
the definition than XPath. I indicated that in the writeup, but perhaps 
it was not clear.

>
>
> 3.2 XSD Approach
>
> The XSD approach couples XSD and WSDL so the messages must be defined 
> at the same time as the Web service. Also, the message must reference 
> the WSDL namespace to pick up the
> wsd:ws-reference-uri type. This seems unwise. WSDL should be able to 
> describe services, not dictate how they are defined. This means 
> existing services cannot be described. The XSD must be redefined to 
> use wsdl:ws-reference-uri and the dervied types based on it. What 
> happens when a new WSDL version is released? Will services have to be 
> redeployed?

I am failing to see the problem you are trying to illustrate. What is 
unwise? Are you arguing the use of a ws-reference-uri type is a bad idea 
or simply writing a wrapper to a uri/ws-reference-uri and providing a 
relationship using the wsdl:endpoint element is not a good idea?

 I don't see  a versioning problem and redeployment problem either. 
Perhaps you can clarify. The approach allows references to existing 
services. This is again due to the fact that only the referrer creates 
these wrappers.The referrer is keeping track of the reference, not the 
service that is being referred to. So, a new version of the WSDL can be 
released independent of who uses it. There are two problems, the 
interface name stays the same or it changes. For the former, there is no 
problem. For the latter, if the service exposes a new interface (type), 
a new reference would need to be defined. This is only natural because 
this is a new type, hence it indicates a different reference.

>
>
> The XSD approach requires the definition of wrapper types, which is an 
> additional authoring burden and which adds bulk to the description.

That is not much bulk to the description. The approach that I am 
suggesting does the wrappering once. It is very simple:

-1- For interface "Foo", you logically create a reference type,  a 
"FooReference" type.
-2- You use the "FooReference "type wherever you need a reference for 
"Foo" in your schema.
-3-You designate this relationship in the wsdl:endpoint elements.

XPath has to do -2- and -3- is necessary for both approaches. The amount 
of bulk suggested by -1- is rather unfair.

In contrast to XPath, the approach is at the type level, not at the 
instance level (as XPath would force us to do). If the schema had choice 
elements, modal groups, etc, one would need to think of how to corrolate 
the schema to the instance document and how the XPath would look like.  
I think this is a discrepancy. We are trying to solve a problem that 
exists at the type level, so it seems to me that XPath is hard to use 
for that reason. Some of my colleagues for the same reason found the 
XPath examples hard to follow for the same reason.

>
> 4. Summary
>
> The XPath approach decouples XSD and WSDL, allows independent 
> authoring of messages and services, and permits greater flexibility in 
> Web service design. However, it introduces another spec, XPath, and 
> may be too powerful.
>
> The XSD approach couples XSD and WSDL, requires coordinated authoring 
> of messages and services, and restricts the design of Web services. 
> However, it introduces no new specs and may be good enough for 80% of 
> the cases. 

This came up during the f2f. If I am not mistaken, David Orchard brought 
this point.

I completely agree with you that the pointer approach (XPath/SCD) is 
more powerful as it decouples the problem. Decoupled approaches in 
general are harder to maintain and describe, but allow greater 
flexibility. However, here is a different way of looking at the utility 
of references. Web service reference is a new concept. A WSDL 
designer/user would require to think of a reference when they are 
designing their interfaces and incorporating a reference to the design. 
I hope we all agree that URIs by themselves do not constitute enough 
information to be regarded as a web service reference. This is why we 
went through this exercise. When you have a reference, you need to know 
where it is in the document and what it corresponds to, namely the 
interface. I would argue the moment you know that this new "concept" is 
available to you, one would incorporate in its design, not through 
XPath, but defining it inthe type system as where it should occur, 
namely using one of the 3 different approaches. I believe people will be 
willing to inline references where they need to create them, not to 
define them external to their definition using XPath as they will think 
of them as a first class concept. Therefore, the distribution is more 
like 90%, 10%.

>
>
> -- Arthur Ryman
>
>
>
>
Cheers,

--umit

The usual references (again):

[1] http://lists.w3.org/Archives/Public/www-ws-desc/2003Jun/0005.html or 
http://lists.w3.org/Archives/Public/www-ws-desc/2003Jun/0024.html
[2]http://lists.w3.org/Archives/Public/www-ws-desc/2003May/0051.html
[3]http://lists.w3.org/Archives/Public/www-ws-desc/2003Apr/0088.html
[4]http://lists.w3.org/Archives/Public/www-ws-desc/2003May/0043.html

-- 
Umit Yalcinalp                                  
Consulting Member of Technical Staff
ORACLE
Phone: +1 650 607 6154                          
Email: umit.yalcinalp@oracle.com