| From | Sent On | Attachments |
|---|---|---|
| Jean-Jacques Dubray | Jun 9, 2004 5:07 pm | |
| David RR Webber | Jun 9, 2004 6:19 pm | |
| Jacques Durand | Jun 9, 2004 8:26 pm | |
| Jean-Jacques Dubray | Jun 9, 2004 9:54 pm | |
| David RR Webber | Jun 10, 2004 7:10 am | |
| Jean-Jacques Dubray | Jun 10, 2004 8:01 am | |
| Yunker, John | Jun 10, 2004 8:18 am | |
| Jean-Jacques Dubray | Jun 10, 2004 11:15 am | |
| David RR Webber | Jun 10, 2004 11:21 am | |
| David RR Webber | Jun 10, 2004 11:35 am | |
| Monica J. Martin | Jun 13, 2004 9:59 pm | |
| Boonserm (Serm) Kulvatunyou | Jun 16, 2004 2:44 pm | |
| David RR Webber | Jun 16, 2004 2:53 pm | |
| David RR Webber | Jun 16, 2004 2:58 pm | |
| Dale Moberg | Jun 16, 2004 3:03 pm | |
| Boonserm (Serm) Kulvatunyou | Jun 16, 2004 3:09 pm | |
| Boonserm (Serm) Kulvatunyou | Jun 16, 2004 3:16 pm | |
| Monica J. Martin | Jun 16, 2004 4:15 pm | |
| David RR Webber | Jun 16, 2004 4:49 pm | |
| David RR Webber | Jun 16, 2004 5:20 pm | |
| Boonserm (Serm) Kulvatunyou | Jun 16, 2004 8:23 pm | .gif, .zip, .zip |
| David RR Webber | Jun 16, 2004 9:26 pm | |
| Hima...@sybase.com | Jun 16, 2004 11:01 pm | .gif, .zip, .zip |
| Monica J. Martin | Jul 13, 2004 1:22 pm | |
| David RR Webber | Jul 13, 2004 2:17 pm | |
| Jean-Jacques Dubray | Jul 13, 2004 2:49 pm | |
| David RR Webber | Jul 13, 2004 7:12 pm | |
| Monica J. Martin | Jul 13, 2004 7:28 pm | |
| Dale Moberg | Jul 13, 2004 8:07 pm | |
| David RR Webber | Jul 13, 2004 8:25 pm | |
| Kenji Nagahashi | Jul 15, 2004 3:39 pm | |
| David RR Webber | Jul 15, 2004 3:59 pm | |
| Monica J. Martin | Jul 15, 2004 4:02 pm | |
| Monica J. Martin | Jul 15, 2004 4:07 pm | |
| David RR Webber | Jul 15, 2004 4:21 pm | |
| Monica J. Martin | Jul 15, 2004 4:26 pm | |
| Kenji Nagahashi | Jul 16, 2004 2:20 pm | |
| David RR Webber | Jul 16, 2004 2:40 pm | |
| Monica J. Martin | Jul 21, 2004 5:48 pm | |
| Steve Capell | Nov 1, 2004 1:58 am | |
| Monica J. Martin | Nov 1, 2004 7:38 am | |
| Dale Moberg | Nov 1, 2004 8:32 am |
| Subject: | Re: [ebxml-bp] State Alignment and Web Services | |
|---|---|---|
| From: | David RR Webber (dav...@drrw.info) | |
| Date: | Jul 13, 2004 2:17:58 pm | |
| List: | org.oasis-open.lists.ebxml-bp | |
Serm,
More on signals - and use scenarios - especially WRT state indication.
1) I believe we have added an additional status of 'pending'. The idea being that you may use a signal to note that some downstream processing has been initiated, and that a complete response will be sent later. This allows your partner to know that the initiating transaction was received, and was understood - but that further processing must occur before a final response happens. This is obviously important in multi-party collaborations, or when using downstream webservices. The difference between a signal and a transaction in this case - is that the signal is informationary - and not legally binding - as a transaction could be construed to be.
2) A signal may occur as a result of some closing condition - either succeed or fail - and is therefore not necessarily associated directly with an initiating transaction within a BTA - and again - is indicating some terminal boundary condition (usually a failure) that cannot be easily done with a formal legal transaction. Or a signal may indicate success in some intermediate step - that shows that progress is continuing toward a formal outcome - eg CreditVerifiedOK, then a subsequent step will see if services can be found to fulfil the request.
Hope that helps.
DW
----- Original Message ----- From: "Monica J. Martin" <Moni...@Sun.COM> To: "Boonserm (Serm) Kulvatunyou" <se...@nist.gov> Cc: "ebXML BP" <ebxm...@lists.oasis-open.org> Sent: Tuesday, July 13, 2004 4:28 PM Subject: Re: [ebxml-bp] State Alignment and Web Services
Boonserm (Serm) Kulvatunyou wrote:
Monica, IVI WSDL attached. I can't help you technically with the WSDL. I hope David can.
I read your quote below and am still confused. First it says "signals when message received for PROCESSING", then it says "business document has been SUCCESSFULLY processed". In my mind, if the document has been successfull y processed the app should return business response like ConfirmBOD or AckPO etc., because the signal cannot precisely indicate which line items are successfully processed, for instance.
mm1: We had good discussion last week in the editors' F2F which you have access to via the notes on Acceptance Ack and its relationship to NOF as well.
Work Item 39 Acceptance Acknowledgment o Signals have technical semantics. RA is structural validation. Any contract formation should be part of a response. Acceptance Acknowledgment can include content validation. o AA guarantees content will be or is being processed. o Separate intent from the technical implementation. o You can bind to attributes that are related to Receipt Acknowledgment. o Legal community should certify technologies that are applicable for a specific jurisdiction. o BPSS is a business state alignment protocol.
Note that we, at least now, we say will or is being processed, not successfully processed. That I believe would be involved with the response. Even in the v1.1, the response is substantive and infer an action against that processing completion. Does this answer your question? Thanks.






.gif, .zip, .zip