Re: [RTF] Behavior definition of Services - public discussion

On Wednesday, July 3, 2002, at 01:07  PM, Champion, Mike wrote:

>>
>> The bottom line: avoid phrasing the question in terms of equivalence,
>> instead phrase the question in terms of `have I heard of this name
>> before'?
>
> My bottom line is
>
>>>> concepts like semantic equivalence that
>>>> could create expectations well beyond what Web Services can actually
>>>> deliver today.
>
> I'm eagerly looking forward to seeing and using technologies using "a 
> graph
> of concepts that a web service provider  publishes to describe his or 
> her
> service. A client applies a matching test to that graph -- which might
> include getting references from other graphs -- to see if the graph is
> congruent with his desired service."  Maybe I'm not looking in the right
> places, but I just don't see that in the real world of web services 
> today.

Its a matter of opportunity and not ruling out the future. Also, I was 
attempting to explain the difference between program equivalence and 
what we are actually likely to be doing.

As far as doing the match, we already do it, just in an exceedingly 
simple minded way (if I know the party, and I see the token I am 
expecting then I'll trust it)



>
> Thus, it is IMHO inappropriate to *require* the WSA to accomodate ideas
> which *may* prove powerful, until their practical value has been
> demonstrated.  The W3C -- to bang one of my favorite drums, sorry -- is 
> most
> successful when working to standardize practice, and least successful 
> when
> trying to do computer science by committee.  I would be very happy to
> incorporate field-tested semantic inference technology into the WSA, 
> but I
> can't agree to require it based on the current state of the art.
>
>

My counter argument here is that currently web services are not being 
deployed in any case because of the chaos of who owns what part of the 
various specifications (W3C, UDDI, WSI, OASIS, ebXML, microSoft, IBM, 
etc.) and how are you going to get a coherent architecture with all of 
that?

In addition there is the issue of `weak technology'. Weak technology is, 
by definition, easy to understand, does a part of the problem but does 
not meet enough of the needs of the domain. Unfortunately, it is often 
also the case that you don't recognize this until after spending a lot 
of time and money in which case everyone says `you can't just junk my 
100K lines of basic)

Currently, if web services can be caricatured as using SOAP with HTTP 
GET to call a method on an object, you have a weak technology because 
there are use cases that I know I want to address that cannot be 
addressed by this. And no amount of fudging will fix it.

Maybe some people would like to deploy CORBA over HTTP, (again, to 
caricature their position), but I am not personally of that persuasion. 
My goal is simple in principle: I want my system to talk to yours, 
without having to have an a priori agreement in place. And I want to be 
able to deliver traditional business (pre-Internet) methods of working 
using modern technology. Easily said, less easily done.

Frank McCabe

Received on Wednesday, 3 July 2002 17:20:15 UTC