Re: SOAP services as database query interfaces / SOAP design patterns?

On Tue, 19 Nov 2002, Jean-Jacques Moreau wrote:

> Would this not be covered adequately by a new SOAP feature[1] ?

Quite possibly. To be honest, I don't know (but I'd like to find out).
The current text introduces the notion of a 'feature' through evocative
examples rather than definition. I'm not sure quite what would count as a
'extension' to the SOAP messaging framework, rather than say a
'characterisation' of the capabilities and characteristics of some
particular class of Web Services.

	[[
	For the purpose of this specification, the term "feature" is used to
	identify an extension of the SOAP messaging framework typically associated
	with the exchange of messages between communicating SOAP nodes. Although
	SOAP poses no constraints on the potential scope of such features, example
	features include "reliability", "security", "correlation", and
	"routing".
	]]

I'd be happy to use SOAP 'features' to classify Web Services that are
variations on the theme of database lookups, though from this text it
isn't immediately clear that this is appropriate. On the one hand, the
SOAP has no hard constraints that stop us from using the 'feature'
feature; on the other, these examples seem to be focussed mostly on the
machinery of communicating with some Service, rather than on
characterising the (meaning/purpose/etc of) facilities offered by that
Service.

I guess there's more than one way to do it, which is often fine. Maybe
this is a point that the Web Services Architecture doc might offer advice
on?

[time passes... skimming specs...]

Looking at http://www.w3.org/TR/2002/WD-ws-arch-20021114/#descstack it
seems my interests live in what the ws-arch doc calls the 'policy' layer,
under '3.3.3.1 Descriptions Applying to a Particular Web Service':

[[
3.3.3.1.3 Policy

Policy for Web services consists of facts, or assertions, and rules that
apply to a particular Web service. The policy may be associated with an
interface (portType), a binding of that interface to a protocol, or a
service instance. Policy would be used to describe or point to documents
describing the owning business, associated products, keywords, taxonomies
for the service, security policies, quality of service attributes, etc.
Policy may be used by the over-arching concerns: security, quality of
service, and management; as well as higher layers of the description
stack.
]]

Are SOAP features considered to be Policies in this sense? Maybe ws-arch
could mention the relationship? eg. a cross-reference from the Policies
section to the discussion of Features at
http://www.w3.org/TR/2002/WD-ws-arch-20021114/#features
SOAP currently says that the specification of a feature must include...

	"A URI used to name the feature. This enables the feature to be
	unambiguously referenced in description languages or
	during negotiation."

This hints at a connection between these two aspects of WS architecture,
but doesn't provide the details. I'm not sure where I'd go for the
details (which working group, which spec(s), ...). WSDL or the WSDL SOAP
Binding? http://www.w3.org/TR/2002/WD-wsdl12-bindings-20020709/#_soap-b

Sorry for all the questions... I'm trying to get a feel for how
all these things fit together. Maybe I should just try creating a Feature
and see whether it seems a good fit for the problem.

cheers,

dan

> Jean-Jacques.
>
> [1]
> http://www.w3.org/2000/xp/Group/2/06/LC/soap12-part1.html#soapfeature
>
> Dan Brickley wrote:
> >
> > www-ws,
> >
> > I was looking again at the registry of (public) SOAP Web Services at
> > http://www.xmethods.com/ and was struck (again) by the fact that many,
> > perhaps most, of these services appear to be based around database
> > queries, ie. they return a single item or list of items corresponding to
> > record(s) picked out by the argument(s) passed in the SOAP request.
> >
> > Lottery results given a region and date. Car rental quotes given a query
> > specification. Zipcode to lat/long mappings. Searches against Shakespeare
> > etexts. Telephone codes from city names. Weather forecasts from zipcodes.
> > Book data given ISBN. Whois lookups. Population size given countrycode.
> >
> > etc etc. You get the idea. SELECT/FROM/WHERE-esque use cases.
> >
> > So I'm interested in whether this recurring pattern of Web Service
> > deployment can be captured for machine use, or less ambitiously, whether
> > anyone has offered a more careful analysis than mine of the ways in which
> > real live SOAP services are being deployed in the public Web as a way of
> > exposing database lookup facilities. I'd like to be able to consult a
> > database of SOAP services and pick out those which offer such lookup-based
> > information services. I'd like to know which of those have an interaction
> > pattern that typically returns a list of 'hits' versus which return a
> > single 'hit'. I'd like to know how each service represents a search with
> > zero hits versus a search that fails for some other reason (malformed
> > query; database temporarily down etc.).
> >
> > Basically it strikes me that there is a lot of hidden commonality across
> > these lookup-based Web services, and that there would be significant
> > benefit to having machine-friendly characterisations of aspects of that
> > commonality. Many of them are probably thin wrappers for SQL queries and
> > ODBC/JDBC/DBI anyway. My current understanding of WSDL and the Web Service
> > Description effort is that it would support richer
> > description/classification of these services, but doesn't come with innate
> > support for representing these.
> >
> > Um, I guess I'm rambling now. The purpose of this mail was to enquire
> > whether folk on www-ws could point me to any work on classifying
> > query/lookup based SOAP services, eg. using WSDL extensions, RDF/DAML-S etc.
> >
> > Thanks for any pointers,
> >
> > Dan
> >
> > ps. this is related to my earlier enquiry about the use of W3C's XQuery
> > for Web Service discovery, see thread beginning
> > http://lists.w3.org/Archives/Public/www-ws/2002Jul/0001.html
> >
> >
>

Received on Tuesday, 19 November 2002 10:00:58 UTC