[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: FW: [ebxml-bp] Figure 21 is better for the comparison RE:[ebxml-bp] Figure 20 from RNIF 20 section 4.6
>-----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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]