RE: Web services and CORBA

Mark,
I read the wiki page, and it seems to me the usual discussion about the
front end of the problem (i.e. how the communication over the Web occurs)
but not any of the harder issues about mapping to executable applications
and how that's done.

The Dell example is particularly telling.  What the person ordering the PC
really wanted was immediate notification of the inventory backorder, and the
ability thereafter to cancel the order.  This requirement led to the
popularity of "online" vs "batch" transaction processing back in the late
70s/early 80s.  Online transactions tie the notion of a communication
session to the result of an operation on data, such that the client program
either (a) receives a communication failure indicating the database was not
updated (b) receives a confirmation indicating that the database was
updated.

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.

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.

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?

Thanks,

Eric

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


On Tue, May 28, 2002 at 07:22:12AM -0400, Eric Newcomer wrote:
> >What would be wrong with building reliability, transactions,
> >conversations, etc.. in the context of hypertext?
>
> Mark can we have some more specific examples here?  I can't answer this on
a
> theoretical basis.  I can see how you can include in XML sufficient
> information to map a transaction context, for example, onto an underlying
> transaction manager.  I do not know of a comparable precedent in
hypertext.

On the RESTwiki, we've got the start of some hypertext purchasing
examples;

http://conveyor.com/RESTwiki/moin.cgi/RestifiedPurchasing

I hope it's clear in there where the notion of a "transaction" would
fit, or where "reliability" would be required, etc..  But it's a bit
rough - Bob Haugen just put it together yesterday.

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 11:43:39 UTC