RE: Web services and CORBA

Bob,

Thanks -- but the point I was really trying to make is that the discussion
has not yet been extended to how to map onto the underlying business systems
that implement the logic.  In the Dell example, this is as you point out,
they didn't join the Web facing and internal systems.  A standard way to
accomplish this would solve the problem.

As you correctly point out, the Web isn't very suitable to traditional
two-phase commit transaction protocols.  Maybe a kind of "latch" mechanism
such as you suggest, and as exists in some message queuing systems (compare
the state on both ends) can provide a partial solution.

I encountered this more than two years ago when sketching out SOAP-TIP with
Don Box (a mapping of SOAP to the Transaction Internet Protocol) -- because
the TIP messages required a connection-oriented protocol, it was obvious the
problem was larger than simply carrying TIP primitives in SOAP headers and
defining a schema for them.

My point is really that we can't afford to dwell entirely in the Web layer
with Web services, since they need to be mapped to executable programs and
objects, many of which understand things like two phase commit, security,
and conversational sessions.

Eric

-----Original Message-----
From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
Behalf Of bhaugen
Sent: Tuesday, May 28, 2002 1:42 PM
To: www-ws-arch@w3.org
Subject: RE: Web services and CORBA


Ok, let's see if I can post to this list...

Eric Newcomer wrote:
> 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.

Just getting started.  I wouldn't have exposed it to this group yet.

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

I suspect what the person ordering really wanted was either
(a) immediate notification that the drive he wanted was out of stock,
with suggestions of substitutes that were in stock, or
(b) a multi-level Available To Promise inquiry (GET) which would say
what's available when.

Dell has internal systems that can give this info, but did not
(in 1998, anway) publish the info as Web resources.

>Transaction processing is indeed a very well established protocol, both
in
> business and in software.

Yeah, but it's established for internal-controlled environments,
not across trust boundaries.  There will be another section on
the Wiki about different transaction models, in particular the
difference between a database or TP monitor transaction and
(for example) a RosettaNet-ebXML business transaction.

Offer-Acceptance is a business transaction.  The goal is state
alignment:  that is, for both parties to agree (and have evidence)
whether the offer was accepted or rejected or there was some
technical problem (which means the transaction failed).

Before the supplier accepts an order, they are supposed to
make sure they can deliver.  (Not that it always happens...)

More discussion at
http://internet.conveyor.com/RESTwiki/moin.cgi/PurchasingBusinessRequire
ments

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

Part of the discussion on the Wiki page will be about what to
publish as Web resources and what to hide behind the Web resources.
Read S080 Transaction in the Web Service Usage Scenarios.
Tell me the WS-Architecture group has this all figured out.
(I'm not saying I do, either, mind you...)

My personal opinion for business protocols is that anything
even remotely resembling a database transaction is not
appropriate for the public or shared interaction across trust
boundaries and should be hidden in the private spaces.
RosettaNet-ebXML-style business transactions - purely
for business state alignment - are more appropriate for
the shared interaction.

-Bob Haugen

Received on Tuesday, 28 May 2002 14:37:11 UTC