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

[<martin.me.roberts@bt.com>]

Martin Roberts 
xml designer, 
BT Exact
e-mail: martin.me.roberts@bt.com 
tel: +44(0) 1473 609785  clickdial
<http://clickdial.bt.co.uk/clickdial?001609785.cld>
fax: +44(0) 1473 609834
Intranet Site :http://twiki.btlabs.bt.co.uk/twiki
pp 16 Floor 5, Orion Building, Adastral Park, Martlesham, Ipswich IP5
3RE, UK 
	British Telecommunications plc 
	Registered office: 81 Newgate Street London EC1A 7AJ 
	Registered in England no. 1800000 
	This electronic message contains information from British
Telecommunications plc which may be privileged or confidential. The
information is intended to be for the use of the individual(s) or entity
named above. If you are not the intended recipient be aware that any
disclosure, copying, distribution or use of the contents of this
information is prohibited. If you have received this electronic message
in error, please notify us by telephone or email (to the numbers or
address above) immediately.



-----Original Message-----
From: Evans,DJ,Derrick,XSG3 R 
Sent: 14 September 2004 12:55
To: Roberts,MME,Martin,XSG3 R
Subject: RE: [ebxml-bp] Figure 21 is better for the comparison RE:
[ebxml-bp] Figure 20 from RNIF 20 section 4.6


Dear All

Martin has forwarded me a discussion in ebxml-bp about the diagrams we
use to describe interactions and the issues of exceptions, timeouts,
retries and NOF.

I would support anything in BPSS that makes it more useful to the
RosettaNet community. 
Having lots of "modular" PIPs using BPSS must be a bonus in promoting
BPSS.

"Our" diagram is an explanation/excuse of how we have built our
implementations. 

Our implementations are not directly related to RosettaNet but are a mix
of our own interpretations of previous BPSS specs, UMM and RNIF.

We... 

* have BPSS collaborations that in general have more than one
transaction activity in them.
* support the use of Receipt AND Acceptance Acknowledgement signals and
their exception forms.
* do not use the "general exception" signal of RNIF. 
* use timeouts for time to acknowledge receipt and acceptance and time
to perform.
* do NOT use retries at all at either the transaction or activity level.
The BPSS editor we use supports the published 1.01 published spec which
doesn't mention retries?
* allow for some individual transactions to be specified WITHOUT either
receipt or acceptance acknowledgement signals (by setting the timeout
properties to p0h).
* 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.
* do not use NOF. 
* do not specfify specific transactions to handle failure transitions
out of transaction activites (we choose either to abort the
collaboration or ignore the failure and allow the collaboration to
continue regardless).


In more detail.

In terms of the use of NOF and the use of exceptions we have made an
interpretation of the guidance in 2.6.4 of RNIF 2.0 (as referred to in a
message from Dale and Hima).

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.

We have not implemented NOF as a transaction on the presumption that a
good number of the failures would be due to platform failures (in which
case NOF might fail also). From what I remember the RosettaNet guidance
is that NOF be implemented as some form of "out of band" communication.

One of the problems with NOF is to understand what it is telling you to
do. As far as I am concerned NOF is just that (a notification of
failure).

We did choose to make use of both receipt and acceptance acknowledgement
signals and their exception forms. 

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).

We also allowed in some cases for receipt and acceptance acknowlegement
to be dropped from the specification of a transaction for "trivial"
transactions.

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.


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).

So

I would like to keep some sort of support for receipt and acceptance
acknowledgement (or some more general ability to do this).

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. 


Retries
In terms of retries the inclusion of a property for business activity
level retries seems fair enough to support RNIF (although we would not
use it!). 

There is a nasty question that arises. BPSS has a property related to
guaranteed delivery which I guess should map to ebXML ms properties. 
ebXML ms also has a retry count and interval. 
Isn't there a danger that people would mix activity level retries with
messaging 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!


NOF

I think this is the toughest one.

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. 

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?

Also in some cases you want NOF to be managed by a different
channel/transport. How would one model that?












	Derrick Evans
	OSS Solution Design
	BTexact Technologies

	e-mail: derrick.evans@bt.com
	tel: +44(0) 1473 609784


	pp 5/16 Orion  House, Adastral Park, Martlesham, Ipswich IP5
3RE, UK

	BTexact Technologies is a trademark of British
Telecommunications plc
	Registered office: 81 Newgate Street London EC1A 7AJ
	Registered in England no. 1800000

	This electronic message contains information from British
Telecommunications plc which may be privileged or confidential. The
information is intended to be for the use of the individual(s) or entity
named above. If you are not the intended recipient be aware that any
disclosure, copying, distribution or use of the contents of this
information is prohibited. If you have received this electronic message
in error, please notify us by telephone or email (to the numbers or
address above) immediately.



-----Original Message-----
From: Roberts,MME,Martin,XSG3 R 
Sent: Monday, September 13, 2004 9:33 AM
To: Evans,DJ,Derrick,XSG3 R
Subject: FW: [ebxml-bp] Figure 21 is better for the comparison RE:
[ebxml-bp] Figure 20 from RNIF 20 section 4.6




Martin Roberts 
xml designer, 
BT Exact
e-mail: martin.me.roberts@bt.com 
tel: +44(0) 1473 609785  clickdial
<http://clickdial.bt.co.uk/clickdial?001609785.cld>
fax: +44(0) 1473 609834
Intranet Site :http://twiki.btlabs.bt.co.uk/twiki
pp 16 Floor 5, Orion Building, Adastral Park, Martlesham, Ipswich IP5
3RE, UK 
	British Telecommunications plc 
	Registered office: 81 Newgate Street London EC1A 7AJ 
	Registered in England no. 1800000 
	This electronic message contains information from British
Telecommunications plc which may be privileged or confidential. The
information is intended to be for the use of the individual(s) or entity
named above. If you are not the intended recipient be aware that any
disclosure, copying, distribution or use of the contents of this
information is prohibited. If you have received this electronic message
in error, please notify us by telephone or email (to the numbers or
address above) immediately.



-----Original Message-----
From: Dale Moberg [mailto:dmoberg@cyclonecommerce.com]
Sent: 10 September 2004 20:27
To: Himagiri.Mukkamala@sybase.com
Cc: ebXML BP
Subject: [ebxml-bp] Figure 21 is better for the comparison RE:
[ebxml-bp] Figure 20 from RNIF 20 section 4.6


Good point Hima, here is Figure 21 which is probably better to use.
Thanks Dale

-----Original Message-----
From: Himagiri.Mukkamala@sybase.com
[mailto:Himagiri.Mukkamala@sybase.com] 
Sent: Friday, September 10, 2004 11:50 AM
To: Dale Moberg
Subject: Re: [ebxml-bp] Figure 20 from RNIF 20 section 4.6






We would be interested in the double action cause single action only has
a request and acks/nofs/exception. No response.



 

             "Dale Moberg"

             <dmoberg@cyclonec

             ommerce.com>
To 
                                       "ebXML BP"

             10/09/2004 11:09          <ebxml-bp@lists.oasis-open.org>

             AM
cc 
 

 
Subject 
                                       [ebxml-bp] Figure 20 from RNIF 20

                                       section 4.6

 

 

 

 

 

 





Hi

Here is the figure about RNIF 2.0 signals (exceptions and NOF) that
documents their behavior.

Monica will resend Martin's Business Activity Behavior diagram.

Our agreed task was to compare the RNIF 2.0 behavior diagram with
Martin's diagram so as to understand how NOF might be added to the
behavior. More generally, it was to reach agreement on how our built-in
signal support (not including any extensibility options David W!!) works
as part of the overall maintenance of state-alignment in BPSS.

If you need more background explanation the 4.6.* sections are good.

Scheduled for detailed discussion Sept 20.

Bye,
Dale Moberg
(See attached file: figure 20.doc)