42 messages in org.oasis-open.lists.ebxml-bpRe: [ebxml-bp] State Alignment and We...| 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 16, 2004 2:40:21 pm | |
| List: | org.oasis-open.lists.ebxml-bp | |
Kenji,
OK - good clarification. I think V2 can support the RosettaNet example by allowing 'pending' as a return state - and then the beginsWhen / endsWhen can be controlled using the new variable mechanism with expressions that check for the conditions between each BTA.
Since a guard condition checks for just succeed or failure, you would need to setup a signal for the pending, but of course - if you look closely - that signal can have a transaction associated with it - so not a problem - as with the RosettaNet case.
Since you talk about this "happening several times" - there must be some kind of "fail" condition - that causes the whole to re-start again from the top. That would obviously need to be "linking and switching" logic that resides above the BPSS - in your implementation layer - that causes the BPSS to be initiated again (possibly with different requirements) to attempt a second or third time.
Perhaps we could model the appropriate PIP using the new BPSS model I have to see how this can all be represented?
Thanks, DW
----- Original Message ----- From: "Kenji Nagahashi" <naga...@fla.fujitsu.com> Cc: "ebXML BP" <ebxm...@lists.oasis-open.org> Sent: Friday, July 16, 2004 5:26 PM Subject: Re: [ebxml-bp] State Alignment and Web Services
Hi
Sorry it was a slip of the finger to write "transport level". I meant "pending" is not part of BT. RosettaNet communicates "pending" through responding action, not through signal.
Buyer sends purchase order request to seller, and the seller sends response message back with line item status set to "pending", thus completing the first BT (PIP). Later the seller initiates another BT to notify the buyer with new value in line item status -- either positive or negative confirmation, or even "pending" again. This could occur many times.
I found some people see this modeling inconvenient and wanted to pack those multiple transactions into one BT, which is not possible with current BPSS. It might have something to do with David's point.
Is anybody really interested in this example?
Kenji
David RR Webber wrote:
Kenji,
Yes - the 'pending' is part of the BTA. I guess in the case of a distributor - it confirms that an attempt is being made to find source(s) for product(s) requested.
In that sense its a binding attempt to provide that, and as you say - the answer could be - 'no source found'.
Thanks, DW
----- Original Message ----- From: "Kenji Nagahashi" <naga...@fla.fujitsu.com> Cc: "ebXML BP" <ebxm...@lists.oasis-open.org> Sent: Thursday, July 15, 2004 6:43 PM Subject: Re: [ebxml-bp] State Alignment and Web Services
Hi,
This "pending" sounds like business level semantics, which should not be handled at the transport level. I can provide an example from RosettaNet which supports such "pending" status response. While the response message itself is legally binding, but you can say "no" later in update message. There might be a confusion about "legally binding". "legally binding" means that you're liable for what you said in the message ("pending" in this case), not for selling something no matter what your downstream supplier say...?
Kenji
David RR Webber wrote:
Monica,
I believe this came out of a scenario that Anders described - where he want to Ack the RFQ - but not confirm it until downstream suppliers had responded.
Therefore 'pending' was offered as an additional status. Anders also wanted to make sure that the signal was *not* a legally binding response - hence 'pending' again avoids that connotation.
It all made sense to me at the time - and I included this in the XML example I posted on signals - along with the additional two attributes - (BTW - signalType - agree that is not needed - and can be deferred to V3).
Thanks, DW
mm1: David, I do not recall that we defin3ed a pending status in the special sessions. Dale, can you confirm please. Thanks.