RE: Web services and CORBA

>Hmm, I thought you said that you wanted to extend the Web.  The Web
>already has a means of purchasing stuff (and doing lots more things).
>Why not work with that?

But this is exactly the point.  The Web by itself is meaningless for
purchasing anything -- it needs to be mapped to existing and new systems
that execute purchase orders and store data reliably.  Unless you're
suggesting the semantic Web replaces SQL, and the TP monitors/app servers
that feed SQL?

If putting the method name in the message helps us achieve this sort of
mapping, it's to the good, isn't it?  And conversely, sticking to
architectural purity that inhibits this type of mapping is to the bad, isn't
it?

Eric

-----Original Message-----
From: Mark Baker [mailto:distobj@acm.org]
Sent: Tuesday, May 28, 2002 12:33 PM
To: Eric Newcomer
Cc: www-ws-arch@w3.org
Subject: Re: Web services and CORBA


On Tue, May 28, 2002 at 11:38:06AM -0400, Eric Newcomer wrote:
> In the Web case, what happens when there's a failure at the HTTP level in
> between the time the order is received and the database is updated?  If we
> don't have a good link between the existing order entry application
(Amazon
> uses TOP END and Oracle, or at least did last I had a chance to review
their
> architecture a couple of years ago -- and they went with TOP END because
of
> Wall Mart, but that's another story) and the Web part of it, we will never
> be able to address the requirements of the Dell scenario.

Exactly!  I'm not saying that the Web solves these problems (well, not
all of them), only that there's value to doing transactibility,
reliability, etc.. for hypertext.

> This whole debate seems to be to be about where to put the information
about
> the program to be accessed by the Web service, in the address itself (or
> associated RDF) or in the message.  I don't see the sense in arguing the
> fine point over whether or not SOAP uses the Web architecture as intended
> unless we can solve this problem better that way.

Hmm, I thought you said that you wanted to extend the Web.  The Web
already has a means of purchasing stuff (and doing lots more things).
Why not work with that?

> Transaction processing is indeed a very well established protocol, both in
> business and in software.  A critical aspect is mentioned on the wiki
page,
> but without reference to established software practice - a transaction
> typically involves two or more related operations on data that must both
> succeed or fail (the payment credit and the inventory debit in this
example)
> and what I'm asking for is how we map a Web service interaction to the
> underlying system or systems that guarantee the two related actions are
> bound.  In particular in the case where the debit (credit card system) is
> remotely accessed using Web services from the inventory system...  How
does
> Web architecture/hypertext help with this problem?

It doesn't (mostly), it just frames the solution space.  Surely you'd
agree that adding transactions and reliability to hypertext shouldn't
require that it stop being hypertext?

MB
--
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@acm.org
http://www.markbaker.ca        http://www.idokorro.com

Received on Tuesday, 28 May 2002 13:36:30 UTC