This document provides a Music information Web service Use Case and WSDL 2.0 description of the use case. It explores how to use the WSDL http binding to describe interactions with an HTTP service. This is an example of music information and purchasing Web service. It is styled after the CDDB database http://www.gracenote.com/gn_products/cddb.html and allmusic.com sites. It has generated a number of questions where I don't think the WSDL as exists can express certain things. I'm grateful for any reviews or comments on this.
An Artist has
Clients have 3 types of interactions: retrieve all/specific information, change/add/delete information, and search based upon a subset of the Artist fields.
Get Artist complete information for a given Artist
Get Artist field contents (Name, Biography, etc.) for a given Artist
Get Artist list by Artist name, genre
Observations on the Artist WSDL and Schema documents
Overall, there is an explosion of schemas and operations that are needed because of the binding. I think this kind of sucks and comes close to making the http binding useless as it stands.
There are 2 variations of identifiers or references shown. The first uses an ID element which can be used to construct a URI at the client. The second uses opaque URIs that the client must use as-is. It seems that it would be useful to combine the XML id attribute or an href attribute with a URI to combine the xml identifier and URI schemes. However, fragment IDs can't be used for server-side secondary resources as the fragment id is illegal in HTTP syntax. Therefore some other syntax, such as query string or URIs would be needed. I tried to show 2 cases, where there was an ID element that the wsdl binding said could be used to generate URIs (client generated URIs) and case where the server generated the URI (opaque URIs). WSDL can't model the typical case of IDs as attributes. There seems to be a need for 2 types of identifiers, opaque and transparent.
In addition to interacting with the resources, it is often desirable to interact with the secondary resources (ie fragments). In general, the Identifier for properties becomes problematic. I've called this the "server-side secondary resource identifier" problem, as we can't use frag-ids when we want to send/receive just the property. The general question of how to specify CRUD methods on properties of resources, ie the Artist things, remains unclear. I created a number of structures for Properties: ArtistIDField to map an ID+fieldname to URI, fieldNameAndValue for updates. I don't think this is expressible in WSDL as the ID can't go in the body.
It is unclear how to model opaque URIs, where the address is not known at WSDL time, from a WSDL perspective. Should the "location" be left blank in the operation and service? Should all of the operations that take in an opaque URI be modeled in a separate interface and then have another service without a location?
Multiple namespace support, particularly Qnames is difficult. It's all well and good if things are in same ns, but then they get hairy if there's multiple ns. I've suggested a variety of Qname to URI mapping schemes.
The goal of using a schema to manage a URI space, that is an XML tree maps to a URI tree, seems hard to achieve as it doesn't seem possible to simply(!) extend a schema and have the URI space that is defined by the schema + WSDL location attributes automagically be updated. If I add another field to Artist, I have to update about 5 different schemas. If I had a sibling to Artist, say Albums, there's no re-use of the operations.
How to describe the situation where part of the message is in the URI and all of it is in the body, specifically a PUT. When generating a URI from an instance, all the contents of the instance are used. But in the case of PUT, only the identifier should go into the URI, not the rest of the instance.
Specifying the exact hierarchical structure that is returned for a given query is complicated. Imagine Music has Artists that have Albums, and I find Albums that were made in 1994. Does that return * or * or *? NodeList is an container invented to provide a root node for returning "leaf nodes". I imagine for each type of return hierarchy, I would need to specify a different URI path component and operation.
Most RESTful Web services, such as Atom and WebDAV, use the HTTP content-location, for the results of PUTS and POSTS. We do not have an accepted way of modelling that this "application data" is bound to an HTTP header. It's at least required that an HTTP header can be described in WSDL, and it would be very useful if the "output" could refer to this directly.
Resource property (aka secondary resources) administration seems problematic. Can properties be "deleted", especially required properties? What happens when a property is added, but it already exists? Is it really an "add if not exist otherwise replace?". If the property type is a list, how is a particular item in the list identified? If I delete a node that is Nillable, is it set to Nil? Is this getting much to close to WebDAV and/or WS-ResourceFramework?
Example: ArtistSearch with 1 parameter
Example: ArtistSearch with no parameters, ie all.
* This assumes the URI="id/xyz"
Thievery Corp version 2Electronicahttp://newbetterthievery.com
* How is the HTTP Content-location mapped to xml in this case? Is it dropped? Should there be XML returned?
* Illegal as the entire Artist will go into the URI
7Thievery Corp version 3Electronicahttp://newwaybetterthievery.com
* Illegal as the entire Artist will go into the URI
* illegal as the opaque URI can't be used
* Illegal as the ID can't get mapped into the body