Re: Semantics of WSDL vs. semantics of service

Bijan,

I appreciate your comments and provide some further clarifications  
below:

On Mar 17, 2006, at 1:34 PM, Bijan Parsia wrote:

> On Mar 17, 2006, at 12:27 PM, Josh@oklieb wrote:
>
>> This discussion is also giving me an inclination towards  
>> preemptive deletion of sws-id emails, which is unfortunate.
>
> That is unfortunate. Though, overall, there's not too much traffic,  
> and really only one determined disrupter.
>
>> Between the confusion of terms (as pointed out, using composition  
>> for binding)
>
> Again, single source.
>
>> and "descent" to XML Schema arguments,
>
> Hmm. What's this? Pointer?

For example, one XML form of an invocation message (e.g. SOAP,  
standalone WSDL) versus another when much the same information needs  
to be carried anyway. Sometimes this seems to involve equating SOAP  
with a simple form of SOAP RPC, which is unfortunate for a more  
generally useful technology.

>
>> it can't be said to advance the cause.
>>
>> It is rather amazing (heartening or disheartening, I'm not sure)  
>> to see arguments rehashed which have been going on in the OGC  
>> (Open Geospatial Consortium) for years. For example, the use of  
>> private XML message schemas versus SOAP formulations, whether  
>> URLencoded service invocations using HTTP GET are still important,  
>> equating SOAP/WSDL with RPC and in turn with the full spectrum of  
>> Web service possibilities, the idea that the useful information  
>> abstractions of WSDL should command  slavish devotion to its  
>> syntax (as well as claim to completeness).
>
> Er...where was this last?
>
> Personally, I don't see any point in departing from WSDL unless  
> necessary. Certainly not at the W3C. The mindshare is compelling.

WSDL has it's place, certainly, but it is neither as flexible nor as  
automatic as some vendors of development systems would have it  
believed. Handling of optional parameters is poor, for example, and  
dynamic binding is quite limited in practice. The service  
descriptions used for OGC services contain much of the same  
information as in WSDL, plus much other information. Some attempts to  
stuff that information into the WSDL syntax have produced WSDL  
documents which are as non-standard as they are disfunctional.

>
>> In truth, and disjoint vocabulary aside, we are all fairly well  
>> agreed on the general information which is needed to productively  
>> discover, bind, and consume a remote service over the Web.
>
> I'm not so sanguine. And, of course, there are details and there  
> are details.
>
>> We should focus on  the substantive general questions that remain.  
>> For instance, is it advisable to abstract away all knowledge that  
>> an operation is being invoked on a remote service over the Web  
>> (probably not)? Should services be self-describing (probably so)?
>
> What does this mean, concretely? It seems like everything points to  
> their *not* being *self* describing (hence, all the  
> descriptions :)). Since we don't have *access* to the "self" of the  
> service, it seems like they can't be.

All OGC services support a "GetCapabilities" operation (and soon a  
"GetWSDL" operation). Practically, any other arrangement ends up in  
some form of disconnection between the service instance and its  
description, various in-progress cataloguing projects aside. This is  
particularly important for services with dynamic coupled content.

>
>>  Is coupled content an important part of service semantics (yes  
>> and yes)? Does WSDL impart all the information needed (for a  
>> machine) to use a remote service outside of a small circle of  
>> friends (no).
>
> Hmm. This is a bit brief. There's a version of the notion of "all  
> the information" wherein the answer is yes. E.g., can a WSDL, using  
> the default vocabulary, be sufficient to using (i.e., invoking) the  
> service? Obviously yes, even outside a small circle of friends.  
> Does pure standard wsdl have any way for me to indicate the  
> *purpose* of so invoking it? Not in any way that doesn't require a  
> person to read some text. (It's not *friendliness* but *out of band  
> knowledge, that circumscribes the set of machines that can sensible  
> use the service.)
>
> Actually, that's not quite true. In principle, if I support the  
> same interface (even though I'm a different service) you can use me  
> in the same way. So once a program "knows" it wants to invoke an  
> operation of a certain interface, it can (in principle) do so  
> regardless of the endpoint, binding (assuming it supports a  
> binding), or Service. This isn't nothing, but it's not a whole lot.  
> One thing we might like is, given that we're want to invoke  
> operation A in interface B, that we would be equally ok with  
> invoking operation C in interface D. (And eventually, instead of A,  
> invoke some composition of E, F, G, H, I...)

There is a theory, I suppose, that everything needed to call an  
operation can be defined in the interface, but I would assert that is  
only achievable in the most simple of cases concerning the domains of  
and correlations between the (input and output) parameters. It is not  
so valuable to develop software which can only invoke a single  
operation on a single interface with a single set of parameter  
options returning a single type of content (e.g. street features from  
the City of Cambridge) and cannot adapt on the basis of service  
information to another service (e.g. with street features from the  
City of Brookline). Even so, development of that software would  
require knowledge about the service which is generally beyond the  
(necessary but not sufficient) descriptive capabilities of WSDL.

There is certainly no such thing as the perfectly soft client and  
will alway be some limited domain of service capabilities that any  
one piece of software can be developed for, but both OGC standard  
service types and OWL-S VM's (to a limited extent as yet) have  
provided some demonstration of a software client being able to "use"  
any of a collection of services using extra-WSDL metadata.

The verb "use" is probably a term we are not at all agreed on. I take  
it to mean something more than "invoke in a syntactically correct  
manner" and something less than "understand fully the purpose of the  
invocation and response". Perhaps we should simply (!) work towards  
service descriptions to enable development of client software which  
allows users (orchestrators?) to get as many different tasks done as  
possible using as many different services as possible, in other words  
keep enlarging the circle of friends...

>
>> Is it important to represent in service information how a service  
>> processes inputs to generate outputs (yes, different geocoding  
>> services for example have their own idiosyncratic heuristics  
>> irrespective of the syntax)? Where are syntax standards useful for  
>> interoperability? Should we get all wound up about whether this  
>> additional service information is contained in a WSDL  
>> <definitions> element, referenced from within a WSDL  
>> <definitions>, outside of a WSDL <definitions>  (not really that  
>> important a question)?
>
> In a sense not all that important. In a sense it has a strong  
> default answer (in). The main point is to do so in whatever way is  
> politically most acceptable (in the sense of not alienating vendors  
> or users).
>
> Cheers,
> Bijan.
>

Received on Friday, 17 March 2006 19:35:26 UTC