20 messages in org.oasis-open.lists.ebxml-bpRe: [ebxml-bp] [12/12/03]: BPSS Signals| From | Sent On | Attachments |
|---|---|---|
| Lars...@teliasonera.com | Dec 12, 2003 10:32 am | |
| Monica J. Martin | Dec 14, 2003 10:51 am | |
| Boonserm (Serm) Kulvatunyou | Dec 28, 2003 6:23 pm | |
| Monica J. Martin | Dec 29, 2003 6:37 am | |
| Boonserm (Serm) Kulvatunyou | Dec 29, 2003 7:23 am | |
| David RR Webber | Dec 29, 2003 8:55 am | |
| Monica J. Martin | Dec 29, 2003 10:30 am | |
| Lars...@teliasonera.com | Jan 2, 2004 4:18 am | |
| David RR Webber | Jan 2, 2004 9:47 am | |
| Yunker, John | Jan 5, 2004 8:45 am | |
| Monica J. Martin | Jan 27, 2004 5:21 pm | |
| Yunker, John | Jan 27, 2004 5:33 pm | |
| Yunker, John | Jan 27, 2004 5:45 pm | |
| Monica J. Martin | Jan 27, 2004 5:45 pm | |
| David RR Webber | Jan 27, 2004 9:23 pm | |
| mart...@bt.com | Jan 29, 2004 1:35 am | |
| Yunker, John | Jan 29, 2004 8:20 am | |
| Hima...@sybase.com | Jan 29, 2004 8:56 am | |
| Duane Nickull | Jan 29, 2004 11:11 am | |
| Monica J. Martin | Jan 29, 2004 5:30 pm |
| Subject: | Re: [ebxml-bp] [12/12/03]: BPSS Signals | |
|---|---|---|
| From: | Boonserm (Serm) Kulvatunyou (se...@nist.gov) | |
| Date: | Dec 29, 2003 7:23:21 am | |
| List: | org.oasis-open.lists.ebxml-bp | |
Monica,
I think the fact is that the more profiles expected in a spec, the more mesh of incompatibility one allows. If you profile such parameter, two systems in fact can functionally interoperate, instead they are not. My concern is whether it is worthwhile to create a potential incompatibility for such parameter. When a parameter is added to a spec and that parameter is not independent of others the number of test cases required will grow by the multiplicative factor. In this case, it at least dependent on the RecAck and AccAck parameters (2 x 2 tests are associated with these two), so roughly speaking we are adding another 4 tests (not yet thinking about how the RecAck and AccAck are dependent on other params). This adds more time and cost to write and execute tests. It has more ramification in interop test. Again, is it worthed.
My 2 cents, - serm
----- Original Message ----- From: "Monica J. Martin" <Moni...@Sun.COM> To: "Boonserm (Serm) Kulvatunyou" <se...@nist.gov> Cc: <ebxm...@lists.oasis-open.org> Sent: Monday, December 29, 2003 9:54 AM Subject: Re: [ebxml-bp] [12/12/03]: BPSS Signals
Boonserm (Serm) Kulvatunyou wrote:
I think these additional sementics poise to two potential issues. 1) It will be more difficult to do conformance and interop testing. 2) It adds more complexity without unique functionality to the spec in which cost vs. value need to be considered. We should not forget about the simplicity side of the spec for SME sakes.
- serm
mm1: Serm: 1) Could not profiling be used to test the more common cases like the IIC created a profile for core or base functionality, then allow other profiles for the more complex or edge cases. The combinations may enable more user flexibility, and profiles could allow that flexibility to be tested for that particular community. 2) If additional attributes or definition was allowed to enable such capabilities and the capabilities were optional, would this be a reasonable tradeoff for any SME user?
What are your thoughts? Thanks.
----- Original Message ----- From: "Monica J. Martin" <Moni...@Sun.COM> To: <Lars...@teliasonera.com> Cc: <ebxm...@lists.oasis-open.org> Sent: Sunday, December 14, 2003 2:06 PM Subject: Re: [ebxml-bp] [12/12/03]: BPSS Signals
The discussion can begin on this during the learning session on Monday.
I will add this as a potential work item to our list as well.
Thanks, Lars.
Lars...@teliasonera.com wrote:
Hi, As input to the learning session coming Monday about BPSS signals I want
to share with you some thoughts and experiences we have found trying to use the BPSS spec.
We want to be informed of receipt errors discovered by our trading
partner validating business Requests coming from us. We also want to be informed of acceptance errors discovered by our trading partner. We therefore enable both the (negative) Receipt Exception signal and the (negative) Acceptance Exception signal by setting a value > 0 in the timeToAcknowledgeReceipt and the timeToAcknowledgeAcceptance attributes.
But at the same time with the current BPSS spec we are also enabling the
(positive) Receipt Acknowledgment signal and the (positive) Acceptance Acknowledgment signal. This means that we receive these positive signals, from our trading partner when he did *not* discover any receipt or acceptance errors, prior to receiving a substantive business Response (in response to our business Request) soon after.
For a business transaction activity that includes both a Requesting
business activity (ReqBA) and a Responding business activity (RespBA), and when the business document in the Request is correct in every sense, this means that we have to receive three messages - two Signals and one substantive Response. In some situations, for example in business transaction activities with short response time ("timeToPerform") this seems to be too many "unnecessary" messages. We think that if we receive a (positive or negative) substantive business Response document it also tells us that there were no (Receipt or Acceptance) errors of any kind in our business Request document.
When there are no errors, we should receive only the (positive or
negative) substantive Response and no positive Receipt or Acceptance Acknowledgment signals, even if we do receive the negative Receipt and/or Acceptance Exception signals when something is in error.
We believe that if we receive a business Response in response to the
business Request, it will imply both a positive Receipt Acknowledgment signal and a positive Acceptance Acknowledgment signal. This means that if the BPSS spec is changed according to our proposal, it will be possible to, in some situations, "save" (not to send) two signal messages.
Of course the positive signals may still be needed in other situations.
We want the BPSS specification to allow us separately for the Requesting
business activity (ReqBA) express that we only want to be informed about receipt or acceptance errors discovered by our trading partner. And we want to be able to express that we *not* want a positive signal, when he did *not* discover any receipt or acceptance errors.
We want the possibility of separately telling our trading partner that we
want to be informed, by a negative signal when he discovers any errors because we think that is something different from telling our trading partner that we want him to inform us, by a positive signal, if he did *not* find any errors.
Even though we sometimes not want the positive Receipt Acknowledgment
signal and the positive Acceptance Acknowledgment signal for the Requesting business activity (ReqBA) we still might want to enable these signals for the Responding business activity (RespBA). Otherwise our trading partner might have to wait until the time-out of the receipts until he can proceed the state of the collaboration because he will never know otherwise if the response was not processed properly. If not, there will always be the ambiguity if our receiving system had been jammed and never got to send that it did effectively process the response message.
* Lars...@TeliaSonera.com * +46 (0) 705 619080 * Kilsgatan 4, Box 299, SE-401 24 Gothenburg, Sweden