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

Dan,

There are now a couple of examples of SOAP features[1,2,3]. I 
don't quite think they would qualify as a Policy as defined by 
WS-Arch. However, Glen Daniels recently gave a presentation[4] on 
features to WS-Arch.

Jean-jacques.

[1] 
http://www.w3.org/2000/xp/Group/2/06/LC/soap12-part2.html#WebMethodFeature
[2] http://www.w3.org/2000/xp/Group/2/07/SOAP-AF/aftf-soap-af.html
[3] http://www.w3.org/TR/2002/NOTE-soap12-email-20020626#correlation
[4] http://lists.w3.org/Archives/Public/www-ws-arch/2002Nov/0085.html

Dan Brickley wrote:
> 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 11:50:05 UTC