Re: Proposed issue; Visibility of Web services

(from www-tag)

Hi again,

On Fri, May 23, 2003 at 08:21:42PM -0400, noah_mendelsohn@us.ibm.com wrote:
> * I claim that there is an additional need.  I have customers, 
> particularly those who use strongly-typed compiled languages, that need to 
> prepare code that will help them use some particular service.  For 
> example, they wish to compile C or Java or Cobol code that populates a 
> purchase order, requests a stock quote or whatever.   I claim that 
> something like WSDL gives them what they need:  a description of some 
> particular service, in a machine-readable form that tools can use to help 
> them build their code.  You seem to object that such contracts are un-Web 
> like.

Correct.  FWIW, most Web services proponents also seem to agree with me
that it isn't Web-like; they just aren't as concerned about it as I am.

> Maybe I could ask this way:  do you believe that my customers should not 
> be looking for such a description?

I believe it is not in their interest to use service-specific interfaces
if they want to expose these services over the Internet.  If they merely
need to publish these services for use on their own Intranet, then,
while a Web-based solution is still preferable IMO, a service-specific
Web services solution could still be used.

>  If so, how would you propose that they 
> build their applications?

I don't have your customer's specific requirements to work from, so it's
hard to say exactly, but my default starting point is to wrap the
service in a HTTP/URI wrapper; exposing resources, using hypermedia to
specify the application state machine, etc..

>  I can assure that dynamic inspection of each 
> SOAP body that comes back is not what they typically want to do (though 
> SOAP can support it, and WSDL is indeed optional.)  Is there another 
> alternative?

What do you mean by dynamic inspection?

> Even with the WSDL description, safe requests can be sent as GET, allowing 
> the web infrastructure that cares only about that level of contract to 
> leverage the power of a limited set of verbs.  I still don't see the 
> problem.

The use of GET in conjunction with service-specific interfaces is, IMO,
an improvement over the alternative of not using it.  It doesn't,
however, change the architectural properties for actions other than
retrieval, such that they would be useable over the Internet.
Specifically, as it relates to my proposed TAG issue, visibility is
poor, and firewalls will not, in general, permit those messages to pass.

MB
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis
  Actively seeking contract work or employment

Received on Sunday, 25 May 2003 23:46:23 UTC