[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ebxml-bp] State Alignment and Web Services
Jean-Jacques, This came out of one of the Friday sessions. As you note - a signal can have a status defined of Success, Fail or Pending - so a ReceiptAck has 'Success', but you may define something like OrderRecvAck and give it a 'Pending' status. The second is all about into the backend processing external to the BPSS - as I believe your notes point up. And - yes - the signals are not intended to be shown in the activity diagram of the collaboration - but are shown in the BTA. My model examples show this usage approach. Thanks, DW ----- Original Message ----- From: "Jean-Jacques Dubray" <jeanjadu@Attachmate.com> To: "David RR Webber" <david@drrw.info>; "Monica J. Martin" <Monica.Martin@Sun.COM>; "Boonserm (Serm) Kulvatunyou" <serm@nist.gov> Cc: "ebXML BP" <ebxml-bp@lists.oasis-open.org> Sent: Tuesday, July 13, 2004 5:54 PM Subject: RE: [ebxml-bp] State Alignment and Web Services 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. <JJ>I am not aware of a "pending" signal. How different would it be from a RecceiptAck? What you are suggesting is the meaning we associated to receipt ack already</JJ> 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. <JJ>I am not sure I understand your point here, could you rephrase it or expand it?</JJ> <JJ>We are adding the notion of notification of failure as standard BT such that we can get extra confirmation of failure condition, this would be typically used on communication failure during a regular BTA. The NoF will have to be choreographed into the collaboration, it will not be sent automatically based on a given condition</JJ> Hope that helps. DW ----- Original Message ----- From: "Monica J. Martin" <Monica.Martin@Sun.COM> To: "Boonserm (Serm) Kulvatunyou" <serm@nist.gov> Cc: "ebXML BP" <ebxml-bp@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 > * Signals have technical semantics. RA is structural validation. Any > contract formation should be part of a response. Acceptance > Acknowledgment can include content validation. > * AA guarantees content will be or is being processed. > * Separate intent from the technical implementation. > * You can bind to attributes that are related to Receipt Acknowledgment. > * Legal community should certify technologies that are applicable for a > specific jurisdiction. > * 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. > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]