- From: bhaugen <linkage@interaccess.com>
- Date: Tue, 28 May 2002 13:42:15 -0400 (EDT)
- To: www-ws-arch@w3.org
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 13:56:01 UTC