Why Web Services are Important


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 14 of 14

Thread: Why Web Services are Important

Hybrid View

  1. #1
    Constance J. Petersen Guest

    Why Web Services are Important

    "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



  2. #2
    Michael D. Kersey Guest

    Re: Why Web Services are Important

    "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

  3. #3
    MMFAN Guest

    Re: Why Web Services are Important


    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



  4. #4
    Michael D. Kersey Guest

    Re: Why Web Services are Important

    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.

  5. #5
    MMFAN Guest

    Re: Why Web Services are Important


    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.



  6. #6
    Michael D. Kersey Guest

    Re: Why Web Services are Important

    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.

  7. #7
    David Bayley Guest

    Re: Why Web Services are Important

    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




  8. #8
    Michael D. Kersey Guest

    Re: Why Web Services are Important

    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.

  9. #9
    David Bayley Guest

    Re: Why Web Services are Important

    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




  10. #10
    Glenn Guest

    Re: Why Web Services are Important

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




  11. #11
    Mike Mitchell Guest

    Re: Why Web Services are Important

    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

  12. #12
    Michael D. Kersey Guest

    Re: Why Web Services are Important

    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

  13. #13
    Kunle Odutola Guest

    Re: Why Web Services are Important

    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



  14. #14
    Michael D. Kersey Guest

    Re: Why Web Services are Important

    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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center