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

On Tue, 19 Nov 2002, Mark Baker wrote:

> I think it's important to note that most of those services you refer to
> at XMethods would best be implemented using either vanilla HTTP GET, or
> HTTP GET via the SOAP 1.2 WebMethod feature[1].  For really complex
> queries, where URIifying the query terms is not practical, the use of
> SOAP/POST may be beneficial, but there's even much better ways to do
> that[2] than most Web services use.

I've a lot of sympathy for this view, esp with respect to the use of GET
when a service has no side effects, which might be just a different
characterisation of the idea of a database lookup.

> So IMHO, I don't think there's much use in trying to optimize for them,
> because query based Web services should be using the optimizations
> already available in GET and URIs.

So, assume they shift to GET-based interfaces. Maybe they're using purest
RESTy XML, or maybe using SOAP-enveloped documents or SOAP-encoded graphs.
Regardless of those details, we still have a huge opportunity here for
better characterising the facilities offered by these services. Think of
the number of Web sites (olde style HTML based sites, even) that offer
ZipCode/Postcode based searches, or ISBN-based lookups, or that can be
keyed into by airport codes, stocktickers or other predictable datatypes,
value sets etc.

My interest is in cataloguing these services, regardless of the mechanics
of interaction with them. I suspect that doing so will help make the case
for careful use of HTTP GET. Once it is easier to find such services (or
'web sites', as we used to call them) it'll be easier to mechanically
generate links into them, which in turn might encourage deployment of
GETable interfaces.

Dan

ps. do you know any URIs for example services that use the SOAP GET
support? It'd be interesting to experiment with use of a stylesheet PI in
these, for linking to XSLT-based UI for web services. I understand SOAP
currently discourages this, but I'd still be interested in seeing whether
its a useful technique...

>  [1] http://www.w3.org/TR/soap12-part2/#WebMethodFeature
>  [2] http://lists.w3.org/Archives/Public/www-tag/2002Jan/0232
>
> MB
>
> On Mon, Nov 18, 2002 at 04:55:17PM -0500, 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
> >
> >
> > --
> > mailto:danbri@w3.org
> > http://www.w3.org/People/DanBri/
>
>

Received on Tuesday, 19 November 2002 10:18:44 UTC