Re: Web Service 'IPersist' Interface?

On Wed, Aug 21, 2002 at 05:11:37PM -0700, David Ing wrote:
> > WSDL is a design-time artifact, whereas
> >you know that a resource is an HTTP resource at runtime, by looking
> >at the URI scheme. e.g. if you see http://www.yahoo.com, you know that
> >you can use HTTP methods, or if you see ftp://example.org/foo.zip, you
> >know that you can use FTP methods.  Very different than with WSDL, where
> >you have to know the type of the service *before* you invoke the
> >methods.  It's a much earlier form of binding than the Web uses.
>
> Good point. But how can I tell that the SOAP node will support the entire
> protocol without having to just 'try it'. I don't really know that
> http://www.yahoo.com will support my DELETE request?

Depends what you mean by "support".  It might not let you delete it,
but it least it knows what you mean.

> Also (detach from
> reality for a moment :) what about SOAP over other protocols than HTTP?

Same deal - use their methods.

> I guess I was alway framing my thoughts/questions in regards to early-bind
> WSDL which is why I fell sideways :) when you suggested HTTP methods.

Many Web services developers don't even acknowledge that the Web and Web
services use different forms of binding, so you're one up on them. 8-)

> >I guess this relates to the comment in your other message, about having
> >trouble reconciling the document-centric use of HTTP and its methods,
> >with the RPC use of SOAP.  It *should* be difficult to do this, because
> >the two approaches are mostly at odds with one another, especially when
> >the common use of SOAP, and the libraries that support this use, eschews
> >the use of URIs.
>
> So I've picked RPC as I need to describe complex behaviour in web services
> but want to find a convention in revealing to people that I do support
> Get/Put/Delete (or Load/Save/Remove) (or Read/Write/Destroy) (or
> Consiga/Puesto/Cancelación :) of my 'objects/docs' without ambiguity in
> names.

That's what the URI scheme is for, as I mentioned.  If you identify all
your important objects with URIs, then they can both accept SOAP RPC
messages *and* HTTP messages.  Indeed, SOAP 1.2's Web Method feature
even encourages such a use.

FWIW, that doesn't mean it's ideal, but it seems like a good path for
Web services developers to follow for now until they find themselves
doing REST.

> >BTW, I should state a disclaimer; I think that Web services are a huge
> >waste of time, and that they completely disregard pretty much all of the
> >important contributions that the Web has made to the design of large
> >scale distributed systems.  So hearing me espouse the value of using
> >HTTP's methods (and extension methods) shouldn't be too surprising;
> >I'm like a broken record in that way. 8-)
>
> Yep, but you took the time to reply, made me think some more and for that
> I'm grateful.

That was my objective.  Thanks for the kind words.

MB
--
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               [email protected]
http://www.markbaker.ca        http://www.idokorro.com

You can read messages from the SOAP archive, unsubscribe from SOAP, or subscribe to other
DevelopMentor lists at http://discuss.develop.com.