Re: Nailing down the definition of "Web services" and the scope o f WS A for the document

Champion, Mike wrote:

>>What does MUST mean?
>>    
>>
>
>It means that for a Web service to be considered in-scope for the WSA, it
>must be defined by a machine-processable WS description language (not
>necessarily WSDL, but something with at least WSDL's power).  In other
>words, the scenario we've discussed where the client programmer calls up the
>service programmer and says "hey, what do you want the SOAP message to look
>like?" is not one that we have to account for in the WSA.
>  
>
That makes perfect sense. +1

>>All of a sudden one of my 
>>disks fails and the document is lost forever. No definition until I get 
>>the time to recreate it which considering the effect of the crash may be 
>>a week or two from now. Do I need to broadcast a message to the world 
>>indicating that my Web service is no longer "a Web service"? 
>>    
>>
>
>We talked about that scenario ... it's sortof like "Is a COBOL program for
>which we've lost the source code still a COBOL program?"  First, I guess
>we're not saying that it's no longer a "Web service", simply that this is
>not a case that the WS Architecture attempts to say anything about.  Second,
>it means that new clients can't be reliably defined, and additional features
>that layer on top of the formal description (such as Choreography, perhaps)
>are undefined.
>  
>
I am actually in support of the concept, just a bit concerned about the
language, that's all.

It didn't made it clear what would happen. If the service is no longer a
Web service I need to notify all its users. If the service is still a
Web service but new clients can't connect, I would consider this a
technical failure and open a bug in Bugzilla.

I am not entirely convienced that the definition of a Web service is one
that must have a machine-processable definition. I think other
possibilities exist and should be considered as valid even if not
practical. I think the definition should be more abstract and simply
state what the principles are. The two principles I see as interesting
is that the service be self-describing and that it can participate in an
ever changing Web of services.

Given such a broad and conceptual definition one must ask what would be
the proper architecture to make it all work. Calling someone on the
phone is a possible solution. It's still self descriptive because the
author tells you what it does and the phone is one mechanism for
communication. And it can still participate in a Web of services if
everyone knows who to call. But an architecture that depends on that
solution is not a scalable architecture.

I am convienced that the use of WSDL (or other) language is the only
option we have to devise an architecture that scales.


I won't be pushing to redefine Web services in terms of more generic
principles, but I do think there's value to it and as a definition it
scales better. It does explain why we are spending so much time and
effort to devise specifications like SOAP and WSDL. Not because a Web
service must use these mechanisms. Simply because that is the only
applicable approach to creating a scalable architecture.

It also reationalizes other specifications all over the spectrum that
attempt to meet these generic principles as part of a scalable
architecture. Choreography is one of them, also RM, security,
transaction protocols, policies, addressing mechanisms, etc. The use of
a general principle will simply guide you to decide which of these
specifications is critical to the success of a scalable WS architecture
without having to constantly revise the WSA document to account for the
ever increasing list of specifications ;-)

arkin

Received on Wednesday, 16 April 2003 23:18:50 UTC