Re: Proposed issue; Visibility of Web services

Mark Baker writes:

> (from www-tag)
> 
> Hi again,

Hi.  I really think I've stated my position, I feel that you've stated 
yours, and we're all going in circles.  In case it helps, I'll do my best 
to reply to your specific concerns below, but I honestly have to move on 
to other things.  It's not that this isn't important, but I don't feel 
we're making progress.  Maybe somebody else will shed light that will lead 
toward consensus, or maybe there's just a disagreement that's a matter of 
perspective or taste.
 
> 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.

Let's try this:  A shipper of boxes offers a web service to track those 
boxes.  Because the've seen the cool REST features of SOAP, they use HTTP 
GET.  Each box is given a URI useable to track its location.  The URI is 
handed out (perhaps by some early WS interaction) and we'll now consider a 
client application that uses the URI to locate the box. 

Let's assume that the service returns application/soap+xml, and that 
successful (non-fault) responses invariably contain bodies that look 
something like this:

      <soap:body>
        <deliveryStatus 
xmlns="http://example.com/shippingcompany/tracking">
          <latestLocation>Chicago</latestLocation>
          <arrivedAtLatest>2003-01-20T12:00:00</arrivedAtLatest>
          <finalLocation>New York</finalLocation>
          <dueAtFinal>2003-01-21T12:00:00</dueAtfinal>
        </deliveryStatus>
      </soap:body>

An HTTP view of this is:  that's fine, but let's not worry about the 
similarity of all these bodies.  You can figure out what you get back when 
it arrives.  Let's agree that the only pre-determined part of the contract 
is URI, GET and media-type.

The Web Services view is:  I'm building a compiled application.  It's fine 
that the Web could in principle return an unexpected media type, or 
unexpected content for the body, but my application wouldn't know what to 
do if a weather report came back anyway. I don't want it to.  This is a 
box tracking application, and I'm perfectly happy to commit in advance to 
that one function...indeed, that's why I'm here!  As author of the 
application, I >wanted< to write code that could deal with the arrival and 
due dates.  I'm really glad that WSDL made it easy.  The shipper made a 
WSDL file available.  My programming tools used that when I wrote my 
application, and did a lot of the grunt work necessary to deserialize the 
shipping information into useful Java (or C or .Net) structures.  It also 
helped me automatically reject certain possible unexpected results (most 
likely resulting from my using the wrong API, or perhaps due to some sort 
of version mismatches between me and the shipper.)
 
> >  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 think I did that.  What I did not do is write a box shipping application 
that went through the motions of being prepared until the last minute to 
deal with weather reports coming back from what I expected to be a request 
for box tracking information.  I compiled in that application dependency 
earlier than I suspect you would prefer.  Trust me, my customers usually, 
but not always, want to do this.  WS architecture lets them.  Those who 
prefer to just discover what comes back on the fly can ignore WSDL 
entirely, and they still have the full power of GET, URIs, media-types, 
and in particular the application/soap+xml media type with its associated 
processing model.

> >  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?

I mean trying to avoid compiling into the application anything more 
specific about expected responses (or required bodies on POST requests) 
than is implied by the media type itself.  I think your objection to WSDL 
is that it requires one to commit early to a contract that is specific in 
the sense of, to use the example above, tracking a box.  Sooner or later 
my code needs to figure out that tracking boxes is what's going on, so if 
it doesn't compile in the dependency statically, I presume it must figure 
out what to do more dynamically.

> > 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.

I'm beginning to think that you are taking a very load/store model of both 
ends of the connection, not just the server.  To return to an analogy I 
(and others) have used before, this is like the IN/OUT model of programmed 
I/O on many processors.  Store to location 1 and the disk seeks, store to 
location 2 and the data goes in a buffer for writing to the disk.  For a 
modem, store to location 1 might dial the phone.  At some level, this is a 
nice uniform model.  On the other hand, there comes a level at which the 
filesystem really, really wants to know that it's writing to a seekable 
disk arm, and not to a modem.  You really do want to know that modems have 
abstractions such as "dial phone", "go into fax mode" or whatever, that 
are effectively specializations of the basic IN/OUT operations.  It's 
perfectly appropriate to compile that level of dependency into the 
filesystem.

I don't know if the analogy is making sense, but I feel that you are 
unwilling to deal with overtly modelling this higher level of application 
processing.  I still think that the reason the "browsable" web gets away 
without such contracts is that there are mostly humans at the client.  If 
you go to weather.com looking to buy a book, it's your human judgement 
that lets you say:  "oops, wrong response to the GET for the form...type 
error...I was expecting an 'order book' form and I got a 'choose a city 
for weather' form instead."  WSDL gives applications the machine level 
tools they need to do the equivalent, and to efficiently generate code.

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


Hope this helps.

Noah

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------

Received on Tuesday, 27 May 2003 17:55:54 UTC