[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: What Does SOAP/WS Do that A REST System Can't?

• To: xml-dev@l...
• Subject: Re: What Does SOAP/WS Do that A REST System Can't?
• From: Michael Champion <michaelc.champion@g...>
• Date: Wed, 30 Mar 2005 15:32:46 -0500
• Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=TmDhHLIYR/2VLEWe1n2O+xJJy3v6hJec+XvyLMaHZdEWj2tJ3eIBnNji0ItdMAx4yAeojKJrAv0RrIGLgBc55iPIHU9xk5tUPfx9YvIXRHcfS4WKOCBbifGFK7z0KLoXsKsZNaJlK8sae6o9KA9F/UVD7qjFji1Dx5Y9OIYt1qg=
• In-reply-to: <15725CF6AFE2F34DB8A5B4770B7334EE07206D59@h...>
• References: <15725CF6AFE2F34DB8A5B4770B7334EE07206D59@h...>
• Reply-to: Michael Champion <michaelc.champion@g...>

On Wed, 30 Mar 2005 11:33:12 -0600, Bullard, Claude L (Len)
<len.bullard@i...> wrote:
>
>, if you don't need a, b and c, REST
> is easier and faster to develop.  OTOH if
> you buy WS* does a, b and c and you get to
> spend more time on the content as long as you
> are happy with vendorZed's implementation of
> a, b and c.

My take is that "a, b, and c" are usually something like
confidentiality, reliability, and protocol neutrality.  If you don't
need these, e.g. you are Bloglines or something and all the
information is public, not mission critical, and accessed only over
the internet, AJAX/POX/Low-REST/whatever you want to call it is the
obvious approach.  If on the other hand you are building systems that
handle confidential information, mission-critical services, and have a
bunch of legacy systems and protocols to integrate, I'd say the burden
of proof is on anyone suggesting something other than WS at this
point.  If you are in the middle, well, life gets interesting.

As for " as long as you are happy with vendorZed's implementation of
a, b and c", the whole point of the XML-based web services stuff is
interoperability so in principle you are not stuck with vendorZed.  In
practice we know that there are nasty corner cases that still bite
people, BUT those nasty corner cases are more in the realm of schema
interop than WS interop.  In other words, assuming that you can define
a business document with a hairy schema and have that interoperate
across l the nodes in your network is a dicey proposition IRRESPECTIVE
of whether you are using a WS/SOA architectural style, a REST/AJAX
architecture, or sending disks around by carrier pigeon.

The schema interop problem is bad enough that the W3C sees fit to hold
a workshop on the subject in June.  See
http://www.w3.org/2005/03/xml-schema-user-cfp

• References:
  • RE: What Does SOAP/WS Do that A REST System Can't?
    • From: "Bullard, Claude L (Len)" <len.bullard@i...>

• Prev by Date: Re: What Does SOAP/WS Do that A REST System Can't?
• Next by Date: Re: What Does SOAP/WS Do that A REST System Can't?
• Previous by thread: Re: What Does SOAP/WS Do that A REST System Can't?
• Next by thread: RE: What Does SOAP/WS Do that A REST System Can't?
• Index(es):
  • Date
  • Thread