How to include domain specific descriptions of your web service

Dear All,

I'm trying to work out how to use WSDL to describe the domain specific
aspects of a particular web service instance.  Let me try to explain
the problem.

Assume there is an industry consortium that agrees on how web
services should operate for a particular domain.  The agreement uses
WSDL to standardise the message: the types, messages, portTypes and
bindings are all defined in a namespace maintained by that
consortium.  Different instances of this service use a WSDL
definition that import all of the above and include a service element
that define the endpoint where that service is available.

However, each compliant service instance needs to describe itself in
a richer way than just using what is provided in the WSDL service
element and its child extensibility element.  For example, a weather
service might want to indicate the geographical region its data is
provided for, the types of measurements it provides, or the charge
associated with using that service.  My question is:

Where should this service instant description information be
located?

[Aside: in case your wondering why I'm asking, I'm working on web
services that provide TV schedule information (see
http://www.tv-anytime.org - a global consortium involving over 100
companies).  The plan is that The TV-Anytime Forum will standardise
a suite of web services for obtaining descriptions of TV programmes,
series of programmes, when they're on etc.  The XML descriptions
have already been standardised and I'm proposing to use SOAP/HTTP as
the transport mechanism.  The idea is that primarily TVs, PVRs and
set-top-boxes (but also PDAs, mobile phones and PCs) will be able to
construct programme guides, search for new programmes, etc.  Users
will be able to discover services that match their needs (schedule
listings for NBC, sites that specialise in movies) and use these to
then record the programmes they find.  TV Anytime will define a
number of different portTypes - for finding metadata on a particular
programme, for searching for a programme, for downloading schedules
and others.  Each instance of these services (provided by different
broadcasters, TV/movie websites, etc.) will need to provide service
specific information. E.g. this schedule service will give you
listings for these channels for this period of time; this search
service specialises in movies and you can search it according to
title, genre, keywords and actors, etc.]

I see three options as to where this service specific description
information could be placed:

1) One or more of the operations of the service is itself used to
describe the functionality of the service; i.e. invoking the
operation returns an XML description of the service's functionality
(the service is self-describing).  I don't like this approach for
two reasons.  Firstly, it mixes up the service's core functionality
and its instance description.  Secondly, it doesn't help clients
discover the service according to the instance description
information - i.e. how does a device find weather services in
Canada that provide wind speed measurements?

2) Define a domain-specific extensibility element that is inserted
in the WSDL instance document.  This could look as follows:

<port name="Weather" binding="tns:WeatherBinding">
  <soap:address location="http://exampleweather.com/weather"/>
  <weather:servicedescription xmlns:weather="http://weather.com/2002/weather">
    <weather:region>US CA</weather:region>
    <weather:measurements>temperature</weather:measurements>
  </weather:serviceDescription>
</port>

It makes sense for the instance description information to be placed
in the WSDL file, but I haven't seen WSDL used in this way.
Extensibility elements usually contain transport binding specific
information, not service specific information.  Also, this still
doesn't help clients discover the service.

3) The WSDL service interface is UDDI registered (given one or more
tModels), and publishers of services also register their service
instance.  Each publisher uses UDDI taxonomies to classify the
nature of their service.  Thus, a UDDI node can be used to discover
the service and to ascertain the service specific description
information.  This seems the best solution, but I have two problems.
Firstly, when the service is not discovered through UDDI, how can a
client determine the service specific information (since the service
is not self-describing)?  I guess one approach would be discover the
service's UDDI key via WS-Inspection.  Secondly, the service
specific description information could be quite rich and
hierarchical - describing such information using UDDI taxonomies
(which are basically key-value pairs) could become quite clumsy
(indeed it might not even be possible).

It seems to me that this must be a pretty common issue, so I'd be
interested to hear how others have tackled it.  Is one of the above
(or some combination thereof) a good solution, or is there a
completely different way of doing it that I should be thinking about?

Many thanks for your help.

Andy Hickman

Philips Research Laboratories


Andrew Hickman
Connectivity Systems Group
Philips Research Laboratories, UK
Tel:  +44 (0) 1293 815167
Fax:  +44 (0) 1293 815500

Received on Friday, 12 July 2002 09:43:10 UTC