Why Web Services are Important

[Constance J. Petersen]

"Mike Mitchell" <kylix_is@yahoo.co.uk> wrote in message
news:3d5f62b3.1846057@news.devx.com...
> Basically, the reason why .Net isn't taking off is that it's a
> solution in search of a problem. Where were business users clamouring
> for web services? Nowhere.

Bzzzt. Wrong.

Just for a start, every app that now has to screenscrape from a Web site is
clamoring for Web services.

And then there's this:

New survey suggests Web services "are being adopted almost universally within
the enterprise."
http://www.webservices.org/index.php...e/view/466/1/7

Or if you need help envisioning the ways, which go far beyond screenscraping,
that Web services will be put to use, consider this:

"In selected industries, such as Finance, Insurance, and Travel, companies are
already beginning to tap into the power of Web Services, enabling them to
integrate easily with new business partners, provide powerful new services to
consumers, and position themselves for long term growth. This article focuses on
how Web Services can revolutionize the Real Estate Industry."
http://www.webservicesarchitect.com/...s/mittal01.asp

That's why every big software vendor is scrambling to support XML Web Services,
not just Microsoft. And, that's why content-rich Web sites such as Amazon.com
are scrambling to offer the Web services their business associates have been
begging for.

--
Constance Petersen, DevX newsgroup section leader
New look; new content: http://www.smartisans.com/
Hot off the press!
"Programming the Web with Visual Basic .NET"
http://amazon.com/exec/obidos/ASIN/1...tancepeterseA/
--
Please reply in the newsgroup so everyone can benefit

[Michael D. Kersey]

"Constance J. Petersen" wrote:
> "Mike Mitchell" <kylix_is@yahoo.co.uk> wrote in message
> news:3d5f62b3.1846057@news.devx.com...
> > Basically, the reason why .Net isn't taking off is that it's a
> > solution in search of a problem. Where were business users clamouring
> > for web services? Nowhere.
>
> Bzzzt. Wrong.
>
> Just for a start, every app that now has to screenscrape from a Web site is
> clamoring for Web services.

"Web Services" are nothing new. Web services written years ago are used
millions of times per day. But the big toolkit vendors would like us all
to *think* Web Services are completely new, only available in the form
of .NET and other costly toolkits. But the truth is quite different.

Web services are available today *without* using the proprietary Web
Service toolkits such as .NET? How can this be?

It's called REST - "Representational State Transfer", and it's been
around since the beginning of the WWW. REST is the architectural style
of the WWW. REST has had full security, encryption, and scalability for
years - everything that the vendors' proposed "Web Services" do not have
today and which given the presence and superiority of the REST
architecture, will likely never have.

The W3C Web Services standards groups are discussing the REST
architecture, with some participants supporting a REST approach and
others (not surprisingly, large vendors who have much invested in their
toolkits) trying to fend off the REST approach:
http://www.w3.org/Search/Mail/Public...LL&type-index=

But the clear superiority of REST is winning people over. Find out how
REST is the only way to do *real* web services *today* and tomorrow.
Here are some links:

Paul Prescod's REST Resources:
http://www.prescod.net/rest/

Paul Prescod: Second Generation Web Services:
http://www.xml.com/lpt/a/2002/02/06/rest.html

Paul Prescod: REST and the Real World:
http://www.xml.com/lpt/a/2002/02/20/rest.html

The REST wiki:
http://internet.conveyor.com/RESTwiki/moin.cgi/

The REST FAQ:
http://internet.conveyor.com/RESTwiki/moin.cgi/RestFaq

Note the "REST and Security" portion of:
http://www.xml.com/lpt/a/2002/02/27/...ty-lather.html

Roy Fielding's doctoral dissertation:
"Representational State Transfer:
An Architectural Style for Distributed Hypermedia Interaction"
http://www.ics.uci.edu/~fielding/tal...9805/index.htm

Roger L. Costello: A REST slideshow:
http://www.xfront.com/REST.html

Roger L. Costello: Building Web Services the REST Way:
http://www.xfront.com/REST-Web-Services.html

Allan Doyle's slideshow on REST and Web services (oriented somewhat to
GIS):
http://lennier.gsfc.nasa.gov/eosig/2...Slide0001.html

[MMFAN]

Will we ever get a REST from the neverending emergence of new Webservice protocols?

"Michael D. Kersey" <mdkersey@hal-pc.org> wrote:
>"Constance J. Petersen" wrote:
>> "Mike Mitchell" <kylix_is@yahoo.co.uk> wrote in message
>> news:3d5f62b3.1846057@news.devx.com...
>> > Basically, the reason why .Net isn't taking off is that it's a
>> > solution in search of a problem. Where were business users clamouring
>> > for web services? Nowhere.
>>
>> Bzzzt. Wrong.
>>
>> Just for a start, every app that now has to screenscrape from a Web site
is
>> clamoring for Web services.
>
>"Web Services" are nothing new. Web services written years ago are used
>millions of times per day. But the big toolkit vendors would like us all
>to *think* Web Services are completely new, only available in the form
>of .NET and other costly toolkits. But the truth is quite different.
>
>Web services are available today *without* using the proprietary Web
>Service toolkits such as .NET? How can this be?
>
>It's called REST - "Representational State Transfer", and it's been
>around since the beginning of the WWW. REST is the architectural style
>of the WWW. REST has had full security, encryption, and scalability for
>years - everything that the vendors' proposed "Web Services" do not have
>today and which given the presence and superiority of the REST
>architecture, will likely never have.
>
>The W3C Web Services standards groups are discussing the REST
>architecture, with some participants supporting a REST approach and
>others (not surprisingly, large vendors who have much invested in their
>toolkits) trying to fend off the REST approach:
>http://www.w3.org/Search/Mail/Public...LL&type-index=
>
>But the clear superiority of REST is winning people over. Find out how
>REST is the only way to do *real* web services *today* and tomorrow.
>Here are some links:
>
>Paul Prescod's REST Resources:
>http://www.prescod.net/rest/
>
>Paul Prescod: Second Generation Web Services:
>http://www.xml.com/lpt/a/2002/02/06/rest.html
>
>Paul Prescod: REST and the Real World:
>http://www.xml.com/lpt/a/2002/02/20/rest.html
>
>The REST wiki:
>http://internet.conveyor.com/RESTwiki/moin.cgi/
>
>The REST FAQ:
>http://internet.conveyor.com/RESTwiki/moin.cgi/RestFaq
>
>Note the "REST and Security" portion of:
>http://www.xml.com/lpt/a/2002/02/27/...ty-lather.html
>
>Roy Fielding's doctoral dissertation:
>"Representational State Transfer:
> An Architectural Style for Distributed Hypermedia Interaction"
>http://www.ics.uci.edu/~fielding/tal...9805/index.htm
>
>Roger L. Costello: A REST slideshow:
>http://www.xfront.com/REST.html
>
>Roger L. Costello: Building Web Services the REST Way:
>http://www.xfront.com/REST-Web-Services.html
>
>Allan Doyle's slideshow on REST and Web services (oriented somewhat to
>GIS):
>http://lennier.gsfc.nasa.gov/eosig/2...Slide0001.html

[Michael D. Kersey]

MMFAN wrote:
>
> Will we ever get a REST from the neverending emergence of new Webservice protocols?
>
That's what's nice about REST - it uses existing WWW protocols to
implement Web Services. So there's nothing new that you must learn! Less
is more, in this case. You must only understand at a deeper level some
things that you probably already intuitively knew about the WWW. Then
you will understand why REST is better than other proposed forms of RPC
Web Services. Apparently the RPC people on the Web Services standards
committees didn't know that there was a better way to do Web Services,
specifically, the way Web Services had always been done in a RESTful
manner. But they are coming around.

[MMFAN]

Personally, I don't think REST stands much of chance of acceptance. As nice
as it would be for innovation to come from some place other than Sun, IBM
or Microsoft, They have done a pretty good job with SOAP and the other webservice
protocols. I'll agree with you that despite what Microsoft and IBM would
like us to believe, webservices are nothing new. That being said, SOAP is
the clear standard. Even google based it's webservices platform on SOAP.

"Michael D. Kersey" <mdkersey@hal-pc.org> wrote:
>MMFAN wrote:
>>
>> Will we ever get a REST from the neverending emergence of new Webservice
protocols?
>>
>That's what's nice about REST - it uses existing WWW protocols to
>implement Web Services. So there's nothing new that you must learn! Less
>is more, in this case. You must only understand at a deeper level some
>things that you probably already intuitively knew about the WWW. Then
>you will understand why REST is better than other proposed forms of RPC
>Web Services. Apparently the RPC people on the Web Services standards
>committees didn't know that there was a better way to do Web Services,
>specifically, the way Web Services had always been done in a RESTful
>manner. But they are coming around.

[Michael D. Kersey]

Notes inline...
MMFAN wrote:
>
> Personally, I don't think REST stands much of chance of acceptance. As nice
> as it would be for innovation to come from some place other than Sun, IBM
> or Microsoft, They have done a pretty good job with SOAP and the other webservice
> protocols.
> I'll agree with you that despite what Microsoft and IBM would
> like us to believe, webservices are nothing new. That being said, SOAP is
> the clear standard. Even google based it's webservices platform on SOAP.
Google had a RESTful (REST + XML) web service in place a year before it
produced the non-RESTful SOAP+RPC version. See "Google's Gaffe" at
http://www.xml.com/pub/a/2002/04/24/google.html for an analysis. And
Google's not the only producer of RESTful Web Services. Both Amazon and
eBay use pure XML, HTTP and URIs for their Web Services as the article
explains.

[David Bayley]

Michael D. Kersey wrote:

> Google had a RESTful (REST + XML) web service in place a year before
> it produced the non-RESTful SOAP+RPC version. See "Google's Gaffe" at
> http://www.xml.com/pub/a/2002/04/24/google.html for an analysis. And
> Google's not the only producer of RESTful Web Services. Both Amazon
> and eBay use pure XML, HTTP and URIs for their Web Services as the
> article explains.

Paul Prescod raises some good questions about the Web Services hype, but
I disagree with most of the criticisms...

For starters, cashing in on the "Web Service" terminology is
disingenuous. HTTP and XML obviously predated Web Services, but REST is
just HTTP. There is nothing new in it AFAICT, apart from the fact that
the GETs return XML rather than HTML. Hardly original, and certainly
nothing compared to the new technology that has been given the term "Web
Services". HTML browsers are just as much of a "web service" as REST if
Prescod is to be believed.

Secondly, Web Services are not limited to HTTP. They are independent of
HTTP, and that is important. You can deploy a Web Service over TCP/IP
on an Intranet, or any other protocol, and switch it over to HTTP as
needed. Mr Prescod seems obsessed with HTTP, and underestimates the
power of protocol independence. Looking to the future, I expect a
standard WS binary protocol, and the WC3 are working on this as part of
the XML InfoSet (in particular for small devices such as Phones/PDAs).

Thirdly, the article makes a big thing about how Google's service adds
so much unescessary type information, and yet admits that the type
information is not nescessary for SOAP. Huh! This is a classic case of
premature optimization. The extra type information is not the
bottleneck for Google's service, it is the network latency and search
processing. If, and only if, it becomes an issue, then Google can refer
you to the XML Schema on their servers so that clients can infer the
type information. This is not a SOAP issue, it is a Google issue.

Fourthly, Prescod doesn't address the issue of munging IN parameters
into the URI. Sure, a simple Google search can be munged in a URI, but
what if the Web Service expects a strongly typed Purchase Order? You
can't munge that into a URI string. Doesn't HTTP limit the length of
the URI string anyway?

And last, but by no means least, Prescod completely discards the value
of Remote Procedure Calls. Web Services are not about distributed
_data_, they are about distributed _services_. A Service, by
definitition, implies some sort of behaviour. Sure, data is transferred
to and from that service, but it is the behaviour that is the point of
Web Services. This is a proven architecture that DCOM, CORBA, and
Java-RMI make use of. The requirement for remote services hasn't
disappeared because of HTTP. The requirement is a standard RPC protocol
that works over, and is independent of, HTTP.

--
David

[Michael D. Kersey]

David Bayley wrote:
>
> Paul Prescod raises some good questions about the Web Services hype, but
> I disagree with most of the criticisms...
>
> For starters, cashing in on the "Web Service" terminology is
> disingenuous. HTTP and XML obviously predated Web Services, but REST is
> just HTTP. There is nothing new in it AFAICT, apart from the fact that
> the GETs return XML rather than HTML. Hardly original, and certainly
> nothing compared to the new technology that has been given the term "Web
> Services". HTML browsers are just as much of a "web service" as REST if
> Prescod is to be believed.

That's why REST is available today and easier to debug and develop than
the RPC approach. And since REST uses HTTP, REST has security today. RPC
Web Services don't have squat today and may never.

Your questions have been addressed by the various links given below.
FWIW you seem obsessed with the single article by Prescod that and are
treating it as if it were the *only* explication of REST and as if
Prescod were the only proponent.

The true situation is that the W3C working groups on Web Services (there
are several) have been discussing REST for quite some time but you and
others haven't been listening. I suggest that you research other links
concerning REST, especially the the W3C working groups on Web Services,
to gain a better understanding of what you are missing. Note that
Prescod was originally *NOT* a supporter of REST, but once he understood
it, he became one of REST's most passionate proponents. Some links:
http://www.w3.org/Search/Mail/Public...LL&type-index=

Roy Fielding's doctoral dissertation:
"Representational State Transfer:
An Architectural Style for Distributed Hypermedia Interaction"
http://www.ics.uci.edu/~fielding/tal...9805/index.htm

Paul Prescod's REST Resources:
http://www.prescod.net/rest/

Paul Prescod: Second Generation Web Services:
http://www.xml.com/lpt/a/2002/02/06/rest.html

Paul Prescod: REST and the Real World:
http://www.xml.com/lpt/a/2002/02/20/rest.html

The REST wiki:
http://internet.conveyor.com/RESTwiki/moin.cgi/

The REST FAQ:
http://internet.conveyor.com/RESTwiki/moin.cgi/RestFaq

Note the "REST and Security" portion of:
http://www.xml.com/lpt/a/2002/02/27/...ty-lather.html

Roger L. Costello: A REST slideshow:
http://www.xfront.com/REST.html

Roger L. Costello: Building Web Services the REST Way:
http://www.xfront.com/REST-Web-Services.html

Allan Doyle's slideshow on REST and Web services (oriented somewhat to
GIS):
http://lennier.gsfc.nasa.gov/eosig/2...Slide0001.html
>
> And last, but by no means least, Prescod completely discards the value
> of Remote Procedure Calls. Web Services are not about distributed
> _data_, they are about distributed _services_. A Service, by
> definitition, implies some sort of behaviour. Sure, data is transferred
> to and from that service, but it is the behaviour that is the point of
> Web Services.

You've missed one of the main points of REST, namely that it supplants
the requirement for arbitrary programmer-defined methods with
established methods available in HTTP. This is why REST Web Services are
available today and can be understood by any (knowledgeable) web
developer who wants to use them. That is why REST provides a transparent
architecture that does not require "tunnelling" through HTTP and that is
why it is straightforward for a developer to write Web Services that use
REST.

> This is a proven architecture that DCOM, CORBA, and
> Java-RMI make use of. The requirement for remote services hasn't
> disappeared because of HTTP. The requirement is a standard RPC protocol
> that works over, and is independent of, HTTP.

There is no RPC protocol in use in any system on the scale of the
internet. The only proven protocols on the internet of the scale
demanded by Web Services are HTTP and email. And as the links above
point out, and as discussed at W3C in the various Web Services working
groups, there are *no* examples whatsoever of large-scale deployments of
DCOM, CORBA or Java-RMI even remotely as large as those already done
using REST. RPC architectures have proven successful only under very
limited and controlled circumstances (e.g., within a single corporation
or between two or three corporations where the developers could meet and
coordinate software interfaces).

Security alone is a nightmare for RPC-SOAP Web Services: vendors are
proposing special Web Services firewalls that look *inside* the SOAP
envelope of each arriving Web Service request to determine whether it
should be accepted. Such a "Web Services firewall" must
1) parse the SOAP envelope (an extremely compute-intensive operation)
and
2) be programmed to recognize the particular RPC request as defined by
the Web Service developer.
What a nightmare! Certainly the hardware vendors are ready and willing
to sell such products since to do so would require that *every* existing
firewall be replaced by a "Web Services firewall"!

In contrast, REST uses existing firewalls, existing security standards
(SSL & HTTPS) and existing protocols (XML) and achieves better results
without adding additional hardware. Here's a link to another thread at
xml.com in a discussion about security and Web Services:
http://lists.xml.org/archives/xml-de.../msg01072.html

I leave it to the market to decide.

[David Bayley]

Michael D. Kersey wrote:

>> For starters, cashing in on the "Web Service" terminology is
>> disingenuous. HTTP and XML obviously predated Web Services, but
>> REST is just HTTP. There is nothing new in it AFAICT, apart from
>> the fact that the GETs return XML rather than HTML. Hardly
>> original, and certainly nothing compared to the new technology that
>> has been given the term "Web Services". HTML browsers are just as
>> much of a "web service" as REST if Prescod is to be believed.
>
> That's why REST is available today and easier to debug and develop
> than the RPC approach. [...]

You've got that the wrong way around. Yes HTTP is available today, but
the reason that so many people are interested in Web Services are
because HTTP doesn't cut it.

> [...] And since REST uses HTTP, REST has security
> today. RPC Web Services don't have squat today and may never.

Total red herring. Web Services over HTTP can use all the security
features (HTTPS, SSL) that REST claims. Web services however are
promoting the WS-Security standards, that maintain independence from
HTTP protocols. You're "may never" FUD, is clearly out of date.

What about Transaction standards? Perhaps these should be munged into
to the HTTP protocol as well. What about SMTP? Perhaps we should
should just discard that rather important messaging protocol, and munge
everything into HTTP headers?

SOAP headers are a) independent of HTTP communication protocols, and b)
extensible through XML formats. HTTP headers are like ASCII INI files
in comparison.

> Your questions have been addressed by the various links given below.
> FWIW you seem obsessed with the single article by Prescod that and are
> treating it as if it were the *only* explication of REST and as if
> Prescod were the only proponent.

FWIW, I started with one of the other Prescod articles you posted. I
found it far too abstract, and thought that this article presented the
case for REST extremely well (at least as well as possible given the
floored foundations). That was why I responded to it. If you can't
defend a well written case for REST, then don't expect me to go hunting
around all the other links you posted in search for an argument.

> The true situation is that the W3C working groups on Web Services
> (there are several) have been discussing REST for quite some time but
> you and others haven't been listening. I suggest that you research
> other links concerning REST, especially the the W3C working groups on
> Web Services, to gain a better understanding of what you are missing.
> Note that Prescod was originally *NOT* a supporter of REST, but once
> he understood it, he became one of REST's most passionate proponents.
> Some links:

<snip link repetition />

Are you human or sheep? I'm not interested in your appeals to
authority. I've already given my arguments against REST, and presumably
the rebel W3C community who agree with Prescod. Respond to the points
you snipped, or don't bother.

>> And last, but by no means least, Prescod completely discards the
>> value of Remote Procedure Calls. Web Services are not about
>> distributed _data_, they are about distributed _services_. A
>> Service, by definitition, implies some sort of behaviour. Sure,
>> data is transferred to and from that service, but it is the
>> behaviour that is the point of Web Services.
>
> You've missed one of the main points of REST, namely that it supplants
> the requirement for arbitrary programmer-defined methods with
> established methods available in HTTP. This is why REST Web Services
> are available today and can be understood by any (knowledgeable) web
> developer who wants to use them. That is why REST provides a
> transparent architecture that does not require "tunnelling" through
> HTTP and that is why it is straightforward for a developer to write
> Web Services that use REST.

It doesn't supplant anything, it is just a bog standard hack of HTTP,
pushing it way beyond what it was designed for. And no, there is
nothing "arbitrary" about programmer-defined methods.

Yes, REST (aka HTTP) is available today. Does the argument for REST
extend beyond that? Web browsers are the here and know, and you can
munge queries into a URI, and get some arbitrary mime type back. The
whole point of SOAP/WebServices is to raise the level of abstraction
beyond that to something that is comparable to COM/CORBA, with the
benefit that it works over HTTP even if you are restricted to such a
poor protocol.

>> This is a proven architecture that DCOM, CORBA, and
>> Java-RMI make use of. The requirement for remote services hasn't
>> disappeared because of HTTP. The requirement is a standard RPC
>> protocol that works over, and is independent of, HTTP.
>
> There is no RPC protocol in use in any system on the scale of the
> internet. The only proven protocols on the internet of the scale
> demanded by Web Services are HTTP and email. And as the links above
> point out, and as discussed at W3C in the various Web Services working
> groups, there are *no* examples whatsoever of large-scale deployments
> of DCOM, CORBA or Java-RMI even remotely as large as those already
> done using REST. RPC architectures have proven successful only under
> very limited and controlled circumstances (e.g., within a single
> corporation or between two or three corporations where the developers
> could meet and coordinate software interfaces).

This is absurd. Of course HTML content over HTTP has been extremely
successful. Don't try to re-claim this success under the "REST" banner.
This what I find most distasteful about your advocacy of REST. Web
Services are not out to achieve the scale of deployment that ZDNet's
"REST" HTML pages do. The B2B market for RPC services is obviously more
limited in scale. What sort of straw man are you building trying to
compare compare Web Services with www.porn-r-us.com?

> Security alone is a nightmare for RPC-SOAP Web Services: vendors are
> proposing special Web Services firewalls that look *inside* the SOAP
> envelope of each arriving Web Service request to determine whether it
> should be accepted. Such a "Web Services firewall" must
> 1) parse the SOAP envelope (an extremely compute-intensive operation)
> and
> 2) be programmed to recognize the particular RPC request as defined by
> the Web Service developer.
> What a nightmare! Certainly the hardware vendors are ready and willing
> to sell such products since to do so would require that *every*
> existing firewall be replaced by a "Web Services firewall"!

I think you are looking at this the wrong way around. The indendence
from HTTP provides an *extensible* security model. If you just want to
stick with HTTP firewalls, then SOAP Web Services won't limit the
ability of existing firewalls in any way.

If you want to extend the firewall to be independent of HTTP, then you
have the choice with SOAP to refine firewalls to a more abstract
application level (i.e. WebService X is public, WebService Y is
private).

> I leave it to the market to decide.

There is nothing to decide. REST is just a further hacking of HTTP that
has been hacked to death already. Web Services are a proposal for
consolidating the various RPC protocols that work on a completely
different level. Web Services _wrap_ HTTP, as well as TCP/IP, SMTP, and
any other communications protocol.

--
David

[Glenn]

I agree with what your saying about the importance of web services. XML, and
now web services came to solve a major problem. Companies and Systems need
to integrate, prior to XML, every company came up with their own spec. Of
course there was EDI, but that has been far from a simple solution, although
many are using it.

However, there has been a huge amount of hype, and prediction about web
services that has not come to fruition. Two years ago I was at VBITS, and
what was the whole seminar about, yep, Web Services. And you would swear if
you attended that convention, that within 3-6 months every company was going
to be popping up with web services. It was going to revolutionize the
industry, and even little mom and pop web sites, would look like Yahoo.
Because, web services were goiing to be the glue that allowed you to
integrate a plethora of functionality that someone else designed, seemlessly
into your web site through SOAP and UDDI.

However, and here's where the hype part comes in, it simply hasn't
happened. Web services have been adopted, but very slowly. Many companies
(not all) think its a cool thing, but simply haven't bought into the whole
idea. Why did Microsoft put their whole Hailstorm passport initiative on
hold? Many analysts say because web services have not been adopted in a
manner that m$ expected. Of course now with .NET it definately makes
integrating / consuming web services much easier for the average user. But,
its still along way from the vision that was pushed for the past few years.


"Constance J. Petersen" <constance@smartisans.com> wrote in message
news:3d5fbe75@10.1.10.29...
> "Mike Mitchell" <kylix_is@yahoo.co.uk> wrote in message
> news:3d5f62b3.1846057@news.devx.com...
> > Basically, the reason why .Net isn't taking off is that it's a
> > solution in search of a problem. Where were business users clamouring
> > for web services? Nowhere.
>
> Bzzzt. Wrong.
>
> Just for a start, every app that now has to screenscrape from a Web site
is
> clamoring for Web services.
>
> And then there's this:
>
> New survey suggests Web services "are being adopted almost universally
within
> the enterprise."
> http://www.webservices.org/index.php...e/view/466/1/7
>
> Or if you need help envisioning the ways, which go far beyond
screenscraping,
> that Web services will be put to use, consider this:
>
> "In selected industries, such as Finance, Insurance, and Travel, companies
are
> already beginning to tap into the power of Web Services, enabling them to
> integrate easily with new business partners, provide powerful new services
to
> consumers, and position themselves for long term growth. This article
focuses on
> how Web Services can revolutionize the Real Estate Industry."
> http://www.webservicesarchitect.com/...s/mittal01.asp
>
> That's why every big software vendor is scrambling to support XML Web
Services,
> not just Microsoft. And, that's why content-rich Web sites such as
Amazon.com
> are scrambling to offer the Web services their business associates have
been
> begging for.
>
> --
> Constance Petersen, DevX newsgroup section leader
> New look; new content: http://www.smartisans.com/
> Hot off the press!
> "Programming the Web with Visual Basic .NET"
> http://amazon.com/exec/obidos/ASIN/1...tancepeterseA/
> --
> Please reply in the newsgroup so everyone can benefit
>
>

[Mike Mitchell]

On Sat, 24 Aug 2002 20:42:49 -0700, "Glenn" <gblock@globalfactory.net>
wrote:

> However, and here's where the hype part comes in, it simply hasn't
>happened. Web services have been adopted, but very slowly. Many companies
>(not all) think its a cool thing, but simply haven't bought into the whole
>idea. Why did Microsoft put their whole Hailstorm passport initiative on
>hold? Many analysts say because web services have not been adopted in a
>manner that m$ expected. Of course now with .NET it definately makes
>integrating / consuming web services much easier for the average user. But,
>its still along way from the vision that was pushed for the past few years.

The whole reason, the only reason for the lack of interest on the part
of corporations is that they still see the whole .Net initiative as a
solution in search of a problem, given that they already have Java for
the "webby stuff". One can bang on about web services for ever, but
until bean counters everywhere can *really* see the savings on the
bottom line, they ain't going budge. I still think web services could
become the next wave of dotcom bubbles as they burst and leave nasty,
sticky stuff (the web) all over many well-fed faces. The whole "web
services" idea is just that: An idea, a back-of-the-envelope
collection of what *could* be done. But until corporates can really
TRUST web services and everything that surrounds them and utterly rely
on them to be dependable, guaranteed 24/7 services and not
DISservices, again, they ain't going to budge. Just about everything
they do currently will accurately justify the watchword: If it ain't
broke, don't fix it. I expect senior management and financial officers
everywhere are continually asking the question of their enthusiastic
IT people: "But what's in it for *me*?"

Answer that question at last (and it's been pending for at least two
years), and you might just have a movement, à la Arlo.

MM

[Michael D. Kersey]

Notes inline...
David Bayley wrote:
> Michael D. Kersey wrote:
> > Google had a RESTful (REST + XML) web service in place a year before
> > it produced the non-RESTful SOAP+RPC version. See "Google's Gaffe" at
> > http://www.xml.com/pub/a/2002/04/24/google.html for an analysis. And
> > Google's not the only producer of RESTful Web Services. Both Amazon
> > and eBay use pure XML, HTTP and URIs for their Web Services as the
> > article explains.
>
> Paul Prescod raises some good questions about the Web Services hype, but
> I disagree with most of the criticisms...
>
> For starters, cashing in on the "Web Service" terminology is
> disingenuous. HTTP and XML obviously predated Web Services, but REST is
> just HTTP. There is nothing new in it AFAICT, apart from the fact that
> the GETs return XML rather than HTML. Hardly original, and certainly
> nothing compared to the new technology that has been given the term "Web
> Services".

HTTP is a protocol defined by rfc2616:
http://www.w3.org/Protocols/rfc2616/rfc2616.html . It's worth reading,
since many web developers are unaware of the details of HTTP and how
well thought-out it is.

REST is an architectural style that builds on the existing WWW and
HTTP: See a "1 Page REST Summary" at
http://lists.w3.org/Archives/Public/...2Aug/0316.html

For a detailed discussion of REST see Roy Fielding's doctoral
dissertation: "Representational State Transfer: An Architectural Style
for Distributed Hypermedia Interaction" at
http://www.ics.uci.edu/~fielding/pub...tation/top.htm

Start at Chapter 5 "Representational State Transfer (REST)"
http://www.ics.uci.edu/~fielding/pub...arch_style.htm
if you're impatient.

> Thirdly, the article makes a big thing about how Google's service adds
> so much unescessary type information, and yet admits that the type
> information is not nescessary for SOAP. Huh! This is a classic case of
> premature optimization. The extra type information is not the
> bottleneck for Google's service, it is the network latency and search
> processing. If, and only if, it becomes an issue, then Google can refer
> you to the XML Schema on their servers so that clients can infer the
> type information. This is not a SOAP issue, it is a Google issue.

It is customary when one has a question about an article to ask the
author. However since you apparently had trouble with another Prescod
article (in your words, "too abstract") and now are apparently having
trouble with a concrete example from a second article, I will address
your questions. Remember that I did not write the article, so I cannot
presume to know fully the intentions of the author.

Firstly, on rereading the article it is clear that you make too much of
Prescod's remarks: he merely points out that:
PP> As you can see, parameters are strongly typed.
PP> Although the client and server know the types
PP> in advance, most SOAP toolkits will inline the
PP> types into the message. As you will see, this is
PP>entirely unnecessary.

and later he states
PP> The client must know the types of the parameters
PP> in order to have made the call. The server must know
PP> the types of the parameters in order to have
PP> implemented the service. Given that both parties
PP> already know the types, it is a waste of bandwidth
PP> to declare the types of the parameters in each
PP> and every message. Even SOAP does not require it;
PP> it's merely a common SOAP idiom.

So this is a criticism of current SOAP toolkits and common SOAP
practices. IOW Prescod is just being a good programmer by pointing out
that the type information is unnecessary (and that specifying type
information explicitly when both client and server have access to a
common definition is a possible source of errors should the reference
type specification(s) change). By referencing a single source for the
type information, the maintainability of the Web Service is increased.
It is also much easier to read;-)

While Prescod covers many specifics in the article (of your choosing, I
might reiterate), you have become ensnared in those details. IMO (at
least one of) his main statements:

PP> The point that has not yet filtered through to
PP> the mainstream of web services implementors is
PP> that linking is just as important for
PP> machine-to-machine applications as it is for
PP> human-facing applications. If it is impossible
PP> to link to SOAP-exposed resources, then they
PP> are less powerful and useful than HTTP-exposed
PP> ones. Until SOAP has an addressing mechanism
PP> as rich as HTTP URIs, SOAP is less, rather
PP> than more powerful than HTTP.

PP> SOAP-based services are called "Web Services"
PP> because their proponents wish to partake of
PP> the Web's success -- yet they don't build on
PP> its core technologies, URIs and HTTP. Somehow
PP> many have equated SOAP and Web Services but
PP> HTTP has been in Service on the Web for more
PP> than a decade now and has not yet hit its
PP> prime. One other question for you to ponder.
PP> If, in general, most deployed Web Services
PP> use XML Schema for definition of types,
PP> language-specific databinding techniques
PP> for interpretation of types
PP> and HTTP for the transport of data,
PP> then what exactly is SOAP doing?

> Fourthly, Prescod doesn't address the issue of munging IN parameters
> into the URI. Sure, a simple Google search can be munged in a URI, but
> what if the Web Service expects a strongly typed Purchase Order? You
> can't munge that into a URI string.
Why not?

FWIW these questions and better ones have been discussed on the W3C's
working group email lists at http://www.w3.org/Search/Mail/Public/
You can find a list of the groups at the W3C main page at
http://www.w3.org/
where on the left-hand side is a list of working groups: click on the
one you want for details.

IOW if you want the best answers then you should go to the source.
(Hint: this means you should quit reading this newsgroup and go read
something worthwhile, such as the W3C's email lists).

Doesn't HTTP limit the length of the URI string anyway?
No. From RF2616 HTTP 1.1 at
http://www.w3.org/Protocols/rfc2616/rfc2616.html :
RF2616> The HTTP protocol does not place any a priori
RF2616> limit on the length of a URI. Servers MUST be
RF2616> able to handle the URI of any resource they
RF2616> serve, and SHOULD be able to handle URIs of
RF2616> unbounded length if they provide GET-based
RF2616> forms that could generate such URIs. A
RF2616> server SHOULD return 414
RF2616> (Request-URI Too Long) status if a URI is
RF2616> longer than the server can handle
RF2616> (see section 10.4.15).
RF2616>
RF2616> Note: Servers ought to be cautious about
RF2616> depending on URI lengths above 255 bytes,
RF2616> because some older client or proxy
RF2616> implementations might not properly
RF2616> support these lengths.

IOW it's a server-defined parameter. You can change it on most servers.

> And last, but by no means least, Prescod completely discards the value
> of Remote Procedure Calls. Web Services are not about distributed
> _data_, they are about distributed _services_. A Service, by
> definitition, implies some sort of behaviour. Sure, data is transferred
> to and from that service, but it is the behaviour that is the point of
> Web Services.

Your first sentence is correct. And that is one of REST's main points.
But on your second sentence REST takes another view: that instead of
tunneling through HTTP to execute (hidden) behaviors as is done in RPC,
Web Services should instead present a representation (a URI) of the
state of the object(s) of interest.

In REST the WWW is a giant virtual state machine: each URI represents a
different state of an application. As operations are performed, the
state of the application changes and the user or caller is pointed to
another (possibly newly-created, possibly not) URI.

Good Luck,
Michael D. Kersey

[Kunle Odutola]

Michael D. Kersey wrote:

> HTTP is a protocol defined by rfc2616:
> http://www.w3.org/Protocols/rfc2616/rfc2616.html . It's worth reading,
> since many web developers are unaware of the details of HTTP and how
> well thought-out it is.
>
> REST is an architectural style that builds on the existing WWW and
> HTTP: See a "1 Page REST Summary" at
> http://lists.w3.org/Archives/Public/...2Aug/0316.html

Yet, you make the claim in your other post today that REST *is* WWW?

Kunle

[Michael D. Kersey]

Notes inline...
"Kunle Odutola
> Michael D. Kersey wrote:
> > HTTP is a protocol defined by rfc2616:
> > http://www.w3.org/Protocols/rfc2616/rfc2616.html . It's worth reading,
> > since many web developers are unaware of the details of HTTP and how
> > well thought-out it is.
> >
> > REST is an architectural style that builds on the existing WWW and
> > HTTP: See a "1 Page REST Summary" at
> > http://lists.w3.org/Archives/Public/...2Aug/0316.html
> Yet, you make the claim in your other post today that REST *is* WWW?
> Kunle

That's incorrect. what I posted was:
MDK> Sorry, but the current WWW *is* REST.
meaning that the WWW architecture is REST. See Fielding's dissertation,
referenced below, for definitions and supporting discussion. My post
continued:
MDK> You might read parts of Roy
MDK> Fielding's doctoral dissertation, wherein the term REST is coined.
MDK> Q. Why should you read it?
MDK> A. Because Fielding is one of the architects of the WWW. He helped
MDK> design and build it and he understands and explains how it works
MDK> and why it does work so well. Fielding's doctoral dissertation is
MDK> "Representational State Transfer: An Architectural Style for
MDK> Distributed MDK> Hypermedia Interaction" available at
MDK> http://www.ics.uci.edu/~fielding/tal...9805/index.htm
FWIW the URI I posted above is for a PowerPoint presentation by Fielding
on REST architecture. My apologies for the incorrect URI: Fielding's
dissertation is available online at
http://www.ics.uci.edu/~fielding/pub...tation/top.htm
and Roy Fielding's home page is at http://www.ics.uci.edu/~fielding/

Good Luck,
Michael D. Kersey