RE: proposed revision text for sect 1.5.3

Mike Champion wrote on 05/31/2003 04:44:10 PM:

> 
> 
> 
> > -----Original Message-----
> > From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
> > Sent: Saturday, May 31, 2003 10:12 AM
> > To: www-ws-arch@w3.org
> > Subject: proposed revision text for sect 1.5.3
> > 
> > 
> 
> Basically, +1 to Chris' proposal -- I agree with the rationale and think
> that the proposal is an improvement.

Thanks!

> > 
> > <proposed>
> > 1.5.3 Service Description
> > The mechanics of the message exchange are documented in a 
> > Web service description (WSD). (See Figure 1.) The WSD is an 
> > extensible  machine 
> > processable specification of the message infosets and features that 
> > comprise the Web service's interface and the binding(s) of those 
> > message infosets 
> > and features to the serialization format(s) and transfer or transport 
> > protocol(s) 
> > supported by the Web service's endpoint(s). It also specifies the 
> > set of endpoints that each expose a network addressable binding to a 
> > specific serialization format and transport or transfer 
> > protocol of the 
> > Web service interface to the service functionality implemented by the 
> > provider agent. 
> > </proposed>
> 
> A couple of points.  First, this section 1.5 is the infamous "what is a 
web
> service" section, so the definition of WSD should be very narrowly 
focused
> on what the minimally necessary degree of description MUST be to be a 
web
> service, not  what the criteria  for a good "web services description

Not sure that I follow. I was describing the aspects of WSDL that I think
are important. And, for the record, I am still very much opposed to any 
effort
to generalize "Web service" for purposes of this architecture document 
that does not have SOAP and WSDL at its core. IMO, interoperability is why
we are doing Web services in the first place, and you cannot achieve
interop if there are thirty one flavors of Web service technology stacks.

> language" SHOULD be. So, "extensible" is not really necessary here, 
although

Ok, I could live with removing that.

> of course WSDL should be extensible.  Sorry if that is overly pedantic 
:-)
> On the other hand, let's make sure we hit the all  basic points of the 
WSDL
> conceptual model that we really need -- the formal description of a set 
of
> concrete operations, collected into one or more machine-processable

I would not at all be comfortable with the term operation used in this
context. I much prefer using the language I had which intentionally does 
not
use the term operation.

> interface, bound to a specific network protocol, and associated with an
> addressable endpoint.  Then there's Roger's point about the sentence 
being
> awkward ...

Upon further review, I agree it could be at least two sentences:)

> 
> So, a proposed further tweak:
> 
>  1.5.3 Service Description
> The mechanics of the message exchange are documented in a Web service
> description (WSD). (See Figure 1.) The WSD is a formal specification of 
a
> Web service's interface: the operations exposed to external users, an
> interface definition of the XML infosets of the data that is passed to 
and
> from the service, the bindings of the interface onto specific messaging
> protocols, and the set of "endpoints," i,e. associations of the 
interface
> definitions with the network address of an agent that implements the
> interface.
>
 
<take3>
1.5.3 Service Description
The mechanics of the message exchange are documented in a 
Web service description (WSD). (See Figure 1.) The WSD is an extensible 
machine processable specification of the Web service's interface. 
It defines the messages that comprise the interface and any features
associated with those messages, such as security and reliability. 
It also defines the binding(s) of those messages and features to 
the serialization format(s), such as SOAP, and transfer or transport 
protocol(s), such as HTTP, supported by the Web service's endpoint(s). 
It also specifies the set of endpoints that each expose a network 
addressable binding of the interface to the service functionality 
implemented by the provider agent. 
</take3>

Cheers,

Christopher Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
phone: +1 508 234 3624

Received on Saturday, 31 May 2003 20:05:10 UTC