RE: Relocating Web services

See inline ...

> -----Original Message-----
> From: www-talk-request@w3.org [mailto:www-talk-request@w3.org]On Behalf
> Of Mark Baker
> Sent: Friday, April 26, 2002 12:04 AM
> To: Anne Thomas Manes
> Cc: Simon St.Laurent; Www-Talk@W3. Org
> Subject: Relocating Web services
>
>
> On Thu, Apr 25, 2002 at 06:31:45PM -0400, Anne Thomas Manes wrote:
> > So here's the question: do the application semantics of HTTP
> define the Web
> > architecture? Does the abuse of HTTP POST constitute a
> violation of the Web
> > architecture?
>
> Yes.

Aren't other protocols (SMTP, FTP, etc) part of "the Web"?

>
> > I don't particularly care where SOAP and WSDL get standardized. I'm not
> > driven to do "the right thing for the Web". I'm trying to do
> the right thing
> > for my customers. I'm working to make SOAP and WSDL better, because my
> > customers are building business applications based on SOAP and WSDL.
>
> Don't you think some of your customers are under the impression that
> they're getting technology that will work as well as the Web has worked?
> All those goodies you get from the Web; scalability, interoperability,
> safety, etc..  I would expect that at least some of them would.
>
> I've been saying all along that there *is* a way to do what Web services
> are trying to do, but in a manner consistent with Web architecture.  I
> would bet that your customers would be really interested in this.

I encourage you to develop your own REST-based approach to doing Web
services and go out and try and sell it. Good luck to you.

I'm not about to follow your lead, though. My customers want SOAP, so that's
what we're building.

One thing that I've learned over the years is that you can't tell customers
that they're wrong. Customers will use and abuse technology as they see fit.
Customers have been abusing the application semantics of HTTP POST right
from the beginning. You won't convince then that your way is better just
because it doesn't violate the Web architecture. You need to show them
tangible benefits to convince them to adopt a new programming model --
benefits that they can't obtain using their current approach (being "better"
isn't sufficient). What makes you so convinced that SOAP won't provide them
with acceptable scalability, interoperability, safety, etc?

Customers aren't driven by architectural purity. Customers are driven by
business requirements. And the business requirement driving SOAP adoption is
the need to make applications communicate with each other as easily and as
inexpensively as possible. Using Internet protocols helps keep things
inexpensive. Using the familiar RPC programming model (or for some a
messaging program model) helps keep things easy. So does the fact that SOAP
can run over any transport protocol.

One of the core features of SOAP is that it's transport independent.
Remember: the customers' goal is to reduce costs, not to communicate over
HTTP. Depending on the requirements of the application, there are times when
they want to use MQSeries or SMTP, or MyOwnFavoriteProprietaryProtocol. By
tying Web services only to HTTP, you are asking the customer to give up
transport-independence. You've got to offer something pretty powerful to
make up for this loss.

REST is a wonderful thing. It's an incredibly powerful disruptive
technology. It has changed the way people search for and obtain information
and entertainment. It's changing the way people compose information. It's
having a huge impact on every form of publishing industry (news, magazines,
books, music, movies, etc.) But that doesn't mean that it should supplant
all other forms of distributed computing -- not even all forms of Web-based
communications.

Anne

>
> > If W3C doesn't want to be a part of this effort, then let's
> just be up front
> > about out. Let's cancel the entire Web Services Activity, and we (the
> > members) will just take our work elsewhere. (Be prepared to
> lose a few of
> > us.) Personally, I'd rather have the standardization effort happen at a

> > venue that isn't trying to undermine the effort.
>
> I'd be all for this.  I would also expect that the fees we'd lose with
> members leaving would be less than the cost for running the Web Services
> Activity.  So I consider that a good thing.  Plus, they'll be back, if
> they don't go out of business first. 8-)
>
> MB
> --
> Mark Baker, Chief Science Officer, Planetfred, Inc.
> Ottawa, Ontario, CANADA.      mbaker@planetfred.com
> http://www.markbaker.ca   http://www.planetfred.com
>

Received on Friday, 26 April 2002 10:08:32 UTC