[wsbpel] wsbpel 4/4/2006: Section 9.2 RejectPO Examples (Update)

[Monica J Martin <Monica.Martin@Sun.COM>]

Feedback appreciated so I can determine what the consensus is on the 
action item. Thanks.

> vanderRijn: You have a good point.  Any idea how the examples should 
> work?  Should we just remove all references to the SP:RejectPO fault, 
> and catching it?  This would leave our examples slightly non parallel, 
> but we could fix that by removing the one-way AsyncPurchaseReject as 
> well.

mm1: At a minimum, I'd suggest we remove the fault. More syntactic savvy 
folk can propose other changes. Thanks.

>> In Section 9.2, there was an addition during the Chapter 9 editing 
>> process to add a fault to the example shown below (SP:RejectPO). This 
>> change was likely made to be consistent with an earlier reference in 
>> the WSDL document for the fault RejectPO.
>>
>>    ...Alternatively, if the request-response purchasing operation is
>>    used in the buyer's business process, the correlation sets are
>>    specified for the request and response messages of the invoke
>>    activity, respectively. The PO rejection from the seller is sent via
>>    a fault message.
>>
>>    <invoke partnerLink="Seller" portType="SP:PurchasingPT"
>>        operation="SyncPurchase"
>>        inputVariable="sendPO"
>>        outputVariable="getResponse">        <correlations>
>>             <correlation set="PurchaseOrder" initiate="yes"
>>                              pattern="request"/>
>>             <correlation set="Invoice" initiate="yes"
>>                              pattern="response"/>
>>        </correlations>         <catch faultName="SP:RejectPO" 
>> faultVariable="POReject"
>>                                          
>> faultMessageType="smsg:POReject">
>>            ...
>>                 <!-- handle the fault -->
>>        </catch>
>>    </invoke>.....
>>
>> I can understand that an external partner may define how this 
>> interface is exposed (and choose a fault). However, it is best 
>> advised to reserve faults to describing program malfunctions rather 
>> than business decisions that may carry other actions and obligations. 
>> I am uncertain we should be encouraging the use of faults, as this 
>> example does, to effect business decisions. Thanks. 
>