1
|
|
2
|
- Give Status of Attributes Task Force
- Motivate the need for Attributes in WSDL
- Propose changes to WSDL
- Build consensus next steps
|
3
|
- 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
|
4
|
- 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
|
5
|
- 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
|
6
|
- OGSI ServiceData
- WebDAV properties
- CORBA IDL Attributes
|
7
|
- 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.
|
8
|
- 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
|
9
|
- <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>
|
10
|
- Binding level description of how attributes are accessed
- Extensible mechanism
- 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
|
11
|
- <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
|
12
|
- 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
|
13
|
- 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
|
14
|
- 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
|
15
|
- Same concept will appear in multiple places
- Narrow set of tooling support
- Two separate groups (Grid, OASIS-WSDM) have specifications for this
concept
|