Report from
the Attributes Task Force
8/1/2003

Purpose of this presentation
Give Status of Attributes Task Force
Motivate the need for Attributes in WSDL
Propose changes to WSDL
Build consensus next steps

What is an Attribute?
Models, as a first class element of an interface description, an element of data that the service wishes to make publicly available.
Example uses
“state data”
“meta-data”
A domain-specific use of data

Motivation
Need a standard, well supported mechanism for defining attributes and a flexible mechanism for defining how the attribute values are read/written.
Needed by at least two constituencies
Grid
Systems Management

Example: Management through Web services
A Web services exposes the management capabilities of a resource, e.g. a W3C working group such as WS-Desc.
A requestor (eg a Management Application) might wish to:
Get working group name
Get chair name
Get names of all HP representatives in the group
Get some or all counters (number of open issues, number of minority opinions filed, number of trouts caught, number of Sanjiva/Tom arguments over last 24 hours…)
Set one or more counters to zero
Get all perf metrics (issue resolution rate, average size of trouts caught…)
Get all attributes of type mgmt:alert and of value “red”
Etc. for other services that implement a “workingGroup” interface

Prior-Art Considered
OGSI ServiceData
WebDAV properties
CORBA IDL Attributes

Alternative Solutions Considered
a) CORBA IDL-like convention
b) similar to a) but single operation, no strong typing
c) JavaBeans pattern
d) a “base” Web services interface that defines the attribute operations.

Proposed Solution
Three Parts:
Declare attribute in the interface
Associate access mechanism via binding
Suggested (small) set of access mechanisms
Analogous to WSDL defining the HTTP/SOAP binding for operations

Attribute Declaration
<definitions>
  <interface>
    <attribute
        element="xs:QName"
        access=(“read”|“write”|“read-write”)? >
  </attribute>*
  <operation … />*
  </interface>
</definitions>
<interface name=“workingGroup”>
  <attribute element=“wg:manager” access=“read” />
  <attribute element=“wg:issues” access=“read-write” />
 
</interface>

Attribute Access Mechanisms
Binding level description of how attributes are accessed
Extensible mechanism
Style identified as URI
Access mechanism designers
Define a URI for their access mechanism
Describe (RDF, English, XML, etc.)
How Attributes are read/written
Other operations on attributes
Binding designers
Associate access mechanisms with their services via binding element
Defining “implicit” operations that become associated with the service to access the attributes

Attribute Access Mechanisms
<definitions>
  <binding>
    <attribute
        element="xs:QName"?
        style="xs:AnyURI" >
  </attribute>*
  </binding>
</definitions>
Note: style can be applied to all (element is optional)
Note: can specify specific styles for particular attributes
Can add binding information for the “implied” operations

Standardized Access Mechanisms
We suggest WSDL should define the URIs and access mechanisms for the following styles:
CORBA-IDL style getXXX/setXXX
Untyped get(xxx)/set(xxx)
Expression-based
Analogous to standardizing SOAP/HTTP binding

Benefits of Declaring Attributes as First Class Components
Notion of attribute without having to search for patterns in operation names
Uniform and flexible access to service’s data
Ability to support other ways of manipulating attributes such as notification (e.g. events)
Ability to model explicit meta-data about attributes

Why not just use Operations?
Volume
Many domains (in Grid, systems management) have lots of attributes
GetXXX/SetXXX becomes unwieldy
Explode WSDL
Explode size of client proxy
More difficult to detect the pattern across all operations and then derive the attribute set
Just use Get(xxx) and Set(xxx)
But how does the Requestor reason about which xxx are valid?
Avoid situation of inheriting unwanted access operations

Why Not Define Attributes Somewhere other than WSDL WG
Same concept will appear in multiple places
Narrow set of tooling support
Two separate groups (Grid, OASIS-WSDM) have specifications for this concept