Re: FW: [ebxml-bp] Figure 21 is better for the comparison RE:[ebxml-bp] Figure 20 from RNIF 20 section 4.6

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

>-----Original Message-----
>From: Evans,DJ,Derrick,XSG3 R 
>Sent: 14 September 2004 12:55
>....We... 
>
>* support the use of Receipt AND Acceptance Acknowledgement signals and
>their exception forms.
>
mm1: From your summary, it is important to note you see effective use of 
both RA and AA, with some distinctions that are important for the user 
community. I hope Derrick and you can attend the call today to discuss.

>* do not use the "general exception" signal of RNIF. 
>....* allow for some individual transactions to be specified WITHOUT either
>receipt or acceptance acknowledgement signals (by setting the timeout
>properties to p0h).....
>
mm1: We discussed this in earlier F2F and allow for extensibility of the 
business transaction patterns to accommodate such specializations.

>* allow for the sending of receipt or acceptance exceptions (EVEN WHEN
>THE POSITIVE FORM OF THE SIGNAL IS EXCLUDED) provided the other partner
>is expecting some form of response which we cannot send for some reason.....
>  
>
mm1: We'd like to discuss this one further.

>We took the view that as long as the initiator of a transaction could
>reasonably be expected to waiting for some sort of response (either a
>business document or business signal) we could send an exception signal.
>
>There is an exception to this which is where a receipt acknowledgement
>and an acceptance acknowledgement have already been sent and then some
>error occurs in the production of a responding business document
>(resulting in the document not being available to send) we send nothing
>back. We took the view that we had "used up" all our signals and should
>just let the transaction timeout....
>  
>
mm1: Could a notification mechanism be used? Another discussion item as 
I believe Anders Tell had asked about notifications with a similar use; 
however, this one is more substantive and, in my view, may justify the 
general exception.

>.....We use Acceptance Exception to indicate a rejection of an inbound
>document BEFORE a target application can persist it (to distinguish this
>from a negative business response from the target application)....
>
mm1: This is good fodder and text for use of AA for our technical 
specification. Comments welcome from the team.

>We also allowed in some cases for receipt and acceptance acknowlegement
>to be dropped from the specification of a transaction for "trivial"
>transactions....
>
mm1: See comment on extensibility of BT patterns.

>Using the guidance of 2.6.4 we took the view that as long a the
>Initiator was waiting from any form of response we could send an
>exception signal instead of the expected response EVEN IF NO SIGNALS
>WERE SPECIFIED TO BE USED. So in a two activity transaction with no
>receipt acknowledgements required we could still send a receipt
>exception instead of the expected responding business document. This
>matches with the notion of the "general exception" signal for which
>there is no positive form and which can be sent after a receipt
>acknowledgement instead of a business response....
>
mm1: Would like to investigate this further.

>So what does this mean from my viewpoint?
>
>Validation
>
>In terms of validation of requests, "in sequence" is important to us as
>collaborations have many transactions and it might be a case of "right
>document wrong state". We also rely heavily on the back end application
>to validate content so acceptance acknowledgement is useful.
>
>For me "in sequence" means in relation to the transactions that precede
>and follow in the collaboration, NOT the sequence of documents and
>signals within the transaction.  From what I remember it is possible for
>a responding business document to arrive in advance of the receipt
>acknowledgement and the transaction still be valid (which is relected in
>the way Martin's diagram is drawn).
>
mm1: Good technical specification fodder.

>....It would be good to maintain a definition of what receipt and acceptance
>acknowledgement means. For me receipt acknowledgement means the correct business document and
>the messsaging middleware can persist it, acceptance acknowledgement
>means the "database of record" has non-substantively accepted the
>document for business processing.
>
>I would like to see some clarity on when one can use the exception form
>of signals. 
>
mm1: Good fodder for technical specification.

>Retries.....Shouldn't BPSS transaction property elements be updated to reflect all
>the QoS attibutes of ebXML ms? Also the ebXML ms QoS features apply to the delivery of the signals as
>well as documents so one can get retries at the messaging layer of the
>retries in sending a receipt acknowledgement in the business activity!
>  
>
mm1: This is part of the harmonization/alignment effort with ebMS, CPPA.

>....I think for BPSS that NOF should be regarded as a transaction in its own
>right to be invoked separately rather than a property of any
>transactions behaviour. 
>
mm1: This was exactly our thought in the editors' F2F in July 2004. We 
indicated it would be another BT.

>I like the idea of an extended set of standardised guard conditions for
>various types of business and technical failure one wishes to trap for
>NOF. This would allow one to model in collaboration when to trap particular
>failures and what sort of transaction(s) are required afterward
>including the use of NOF. This would have to include an understand on
>whether the timeout or processing problem was on the initiator or the
>responder side. This would allow RNIF specs to be explicit about when NOF is to be used
>or not. This would be at the expense of the PIP blueprint BPSS needing a
>collaboration which includes both the transaction being defined and the
>use of NOF as separate transactions rather than a blueprint of a single
>transaction and its properties.
>
>A problem with modelling NOF in this way is that it is a transaction
>activity that can be initiated by either party depending upon when the
>error occurs so which role would you assign as initiator?
>  
>
mm1: We should consider this final question.

>Also in some cases you want NOF to be managed by a different
>channel/transport. How would one model that?
>
mm1: That's a question for CPPA.