Re: Cancellability and two-phase events

> I haven't been able to do this on the standard DOM 2 API, but that doesn't
mean it can't. I would be very interested if anyone has a clue on how it can
be done. 
I have no solution to this question but would like to submit the following
classical use case:

1.- The use case:
 1. a purchase order (PO) with a collection of items (ITs) exists
 2. the PO contains an element: POValue := Sum Of ITValues
 3. where ITValue := some complex (ITUnitPrice*ITQuantity ( 1 - ITDiscount))
formula  
 4. the ITQuantity of one of the ITs must be changed (increased)
 5. there is a business rule that states that POValue must not be greater
than 1.000 Euro.

2.- If I understand correctly the capture/bubble model (I am not an expert):
 1. the POValue could be set for a captureEvent before the ITQuantity gets
changed
 2. however, POValue would be embarassed to perform the verification right
now, since it relies on ITValue that cannot be computed yet
 3. so, the request reaches IT where ITQuantity is set to the new value
 4. now, the event bubbles back to PO where the business rule can be
validated.

3.- Question:
 1. how can PO now veto the update of the IT ?
 2. if a 2PC mechanism were available, IT could be notified to not commit
(whatever that means exactly (*)) the new ITQuantity change
 3. in the absence of such mechanism, the classical 2PC solution applies:
    3.1. a (dynamic) tree (set?) of involved nodes (here 2 nodes) must be
maintained,
    3.2. the nodes must be informed to rollback to the previous state,
    3.3. a 'master' node is required (which one?) to instruct all
participating nodes that 'it is time to commit/rollback'.
    3.4. question: is this sensible and can this be implemented with
existing means ?
 4. (*) notice that PO transiently requires IT to have the new ITQuantity at
hand to validate the business rule, before it will eventually veto

4.- And what if ?
 1. what if one of the nodes that participates in the business rule is not
an ancestor of the IT node
 2. this could be the case where - inside the PO - there exists a related
node, e.g. 'delivered IT' that would veto the change of the IT because it
has been delivered already.
 3. in that case, I believe that the captureEvent model would apply to the
PO node, but not apply to the 'delivered IT' node
 4. this case seems to suggest that the 2PC 'business rule' dynamic tree
(involving now 3 nodes) does not necessarily map upon the physical static
document tree with respect to the capture/bubble scenario.  
 
Comments and suggestions are welcome. Many thanks,

Marc.

Received on Wednesday, 4 October 2000 11:38:38 UTC