Comments on “Report from the Attributes Task Force”
This document presents the views of Savas Parastatidis and Jim Webber on the “Report from the Attributes Task Force.” We are sending this document to the same mailing lists the report made its first appearance. We understand that as non-members of the task force we could not have participated in the voting/editing process for this report. Although the discussions were always open through the task force’s mailing list we felt that we should present our views to the WSDL community by discussing the report point-by-point (our comments appear in black… apologies for sending HTML).
The Attributes Task Force was chartered to consider the requirements for modeling attributes, or elements of publicly available state of a Web service, in WSDL.
Nowhere in the Web Services Architecture (WSA) the concept of “publicly available state” of a Web Service is defined. We believe that there is no problem that needs to be addressed. We understand the need for giving the flexibility to Web Service interface designers in various applications domains (e.g., Grid) to define ways of exchanging messages that result to an “attribute” operation. However, we believe that unless “attribute” and “Web Service state” have specific meanings within the WSA, WSDL can only provide a wsdl:attribute element as a specialisation of message description and nothing more.
We have gathered requirements and explored various alternatives and precedents in the industry, including: WebDAV, CORBA IDL attributes and OGSI ServiceData.
This document summarizes our analysis and a recommendation to the W3C Web Service Description Working Group.
The following are the requirements gathered by the Attributes Task Force[1]. The solution must allow or support:
1. The user should be able to know what their permissions are on attributes before trying to access the attribute.
We believe that this requirement is orthogonal to WSDL. The way access to a wsdl:attribute is restricted should not differ from that of a wsdl:operation. There are other, security-related, specifications that deal with access policies and permissions. Although the report concludes that this is not addressed, we believe that this shouldn’t even be a requirement.
2. Query across attributes (in one service) by some query language.
Query across attributes of a Web Service would make sense only if the WSA defined the semantics of what it means for a service to have state and attributes.
3. The user to know a (potentially partial) list of attributes at design time. This implies that additional attributes may appear at runtime. OGSI calls this facility “dynamic serviceData”.
This suggests that the interface of a service may change at runtime. We believe that this is bad practise and should not be encouraged. Currently, there is nothing in the WSDL specification to restrict tool vendors from changing the operations in the public interface of a Web Service after that service has been deployed. However, a change to an interface should be accompanied by a change in the namespace in which that interface is defined. We believe that interfaces should be immutable and appropriate naming convention adopted as interfaces are changed over time (though this is itself outside the scope of the WG).
4. Ability for the user to know type of attributes ahead of time
5. Input/output messages that manipulate attributes can be validated against WSDL
6. Static attributes
What are the semantics of a “static attribute”? What does it mean for a Web Service to expose a static attribute?
7. Ability to restrict access on a per attribute basis.
Not different from 1 and not an issue that WSDL should address.
8. Ability to restrict read vs. write access
9. Attributes inheritance through WSDL 1.2 interface inheritance
10. Metadata on attributes (creation date, type, description...)
An attribute is part of the interface of a service. What are the semantics of a “creation date” metadata?
11. Bulk retrieval of several attributes in one operation
This is tantamount to specifying the base interface for all Web services, and is in our opinion out of scope, though it definitely is in scope for particular application frameworks like OGSI.
12. Attributes can be of any schema type (simple or complex)
The attributes task force proposes the inclusion of attribute declarations to WSDL interfaces as presented in this document. Declaring attributes in the WSDL interface provides a uniform way of declaring information items constituting the publicly available state of a Web service that can be accessed or modified by Web service requestors.
The above paragraph introduces semantics to Web Services that do not exist in WSA. What does it mean for a Web Service to have “information items constituting the publicly available state […] that can be accessed or modified…”? There is nothing in WSA to support this. We believe that WSDL should be an interface description language of the semantics defined in WSA.
Based on the experience gained in OGSI, we assert that providing a syntactic convention for declaring attributes in the interface with accessibility options is useful for tools to build systems.
This syntactic convention is associated with a very flexible mechanism to associate access mechanisms with the attribute declaration.
The proposed solution has two components:
A mechanism to define Attributes as part of an interface definition;
A mechanism to describe how Attributes and their values can be manipulated.
Once attributes have been introduced to a WSDL interface and the necessary bindings have been added, the way they are “manipulated” should be application specific.
A designer uses the attribute element to specify the names and types of attributes associated with an interface. The attributes represent elements of publicly available state. These elements may be read or written. The exact means by which a requestor accesses attributes is determined by the access mechanism(s) specified in the binding.
<definitions>
<interface>
<attribute
name="xs:NCName"
type="xs:QName"
access= “read” | “write” | “read-write”? >
<documentation />
</attribute>*
</interface>
</definitions>
We propose to add an additional component, named attribute, as child of the interface element.
The properties of the Attribute Component are as follows:
· {name} An NCName as defined by [XML Namespaces].
· {target namespace} A namespace name, as defined in [XML Namespaces].
· {type} A reference, by QName to a Global XML element.
· {access} A fixed enumeration of strings (“read” or “write” or “read-write”).
An interface could have zero or more attribute element children. Each element defines a single attribute. Constraints on the values of name property are the same as constraints on the operation name property.
There is no guarantee that the list of attributes provided in the interface is the complete list of attributes available, it is only a minimum, required list. Attribute access mechanisms are free to define operations to access attributes not defined in the interface, for example by providing a way to retrieve a list of attributes at runtime.
As described above, we believe that the notion of altering the interface of a Web Service at runtime is going to cause interoperability problems.
<definitions>
<binding>
<attribute
name="xs:QName"?
style="xs:AnyURI" >
<documentation />?
</attribute>*
</binding>
</definitions>
The set of operations or messages that allow requestors to read and/or write elements of a service’s publicly available state is specified by the attribute element child of a binding.
The properties of the Attribute Component are as follows:
· {name} A reference, by QName to an attribute declared in an interface.
· {style} A URI, which defines in the mechanism by which attributes can be manipulated by a requestor.
If an attribute element is defined without a value for the name attribute, it is considered to define a generic access mechanism available for all attributes associated with the interface. It is legal to define zero or more such generic access mechanisms.
If an attribute element is defined with a name value, then the access mechanism applies only to the named attribute. The access mechanism described in this manner is in addition to the set of “generic” access mechanisms that may be associated with the binding. It is legal to define zero or more access mechanisms for a specific attribute.
Through a combination of “generic” and named attribute bindings, all attributes defined in the interface MUST be associated with at least one access mechanism.
Because the set of attributes for an interface may be a superset of the attributes defined in the interface, it is legal to include an attribute element in the binding that refers to (by name) an attribute that does not appear in the attributes listed in the interface. Although this is a deviation from how bindings refer to operations in interfaces, it is required for attributes to support the notion of “dynamic attributes” as suggested from the OGSI work. Attributes not listed in the interface can also be accessed through a generic access mechanism if there is some means by which the requestor can discover the list of attributes available at runtime.
A binding mechanism specifies the way a message described in WSDL is to be transmitted via a particular network protocol (e.g., SOAP over HTTP, HTTP, TCP/IP, Pigeons, etc.). We believe that a binding mechanism similar to that used for an operation is enough:
<definitions>
<binding>
<attribute name=”xs:NCName”?>
<documentation/>?
</attribute>*
</binding>
</definitions>
In the case of SOAP binding, a new element will be required.
<definitions>
<binding>
<attribute>
<soap:attribute uri=”uri”? />
</attribute>
</binding>
</definitions>
We believe that the discussions about different access mechanisms are not relevant to WSDL. However, we provide some comments.
The access mechanism identified by the URI value of the style attribute defines the semantic of how the attributes declared at the interface level can be accessed. The designer of the attribute binding chooses access mechanisms from one of possibly many different choices.
What does an “access mechanism” mean? A Web Service accepts or sends messages. It can’t provide “access mechanisms”.
The creator of an access mechanism is free to use any approach he or she chooses to define the access mechanism, be it pure English or a mix of WSDL constructs and English, RDF, etc. Nevertheless, the description of the access mechanism must provide enough information for the requestor to derive a set of named operations (and their signatures) as well as the QName of an interface containing all the operations in the access mechanism.
What does it mean to “for the requestor to derive a set of named operations (and their signatures” at the binding level? Surely, the way a tool provides programmatic support to send/received messages to/from attributes of a Web Service should not be reflected at the interface level.
We believe that the text describing access mechanisms is not relevant to WSDL.
.savas.