Re: [ebxml-bp] [12/12/03]: BPSS Signals

["David RR Webber" <david@drrw.info>]

Serm,

+1.

It's crazy to have three or four messages exchanged here.

The answer would appear to be - that one message can
indicate multiple things - I would suggest:

1) Acceptance Acknowledgement is also implied Receipt Ack
    so no need to send RecAck if you send an AccAck (timing
    is something you need to determine -if your business process
    may mean a time-out could occur between receipt and
    calculating the acceptance - then you will need to send both).

2) Negative Receipt and Acceptence Exception - clearly these
    are different - so you need to be able to handle both these
    conditions - and you should only get one of these at a time.

DW.

----- Original Message ----- 
From: "Boonserm (Serm) Kulvatunyou" <serm@nist.gov>
To: <ebxml-bp@lists.oasis-open.org>
Sent: Monday, December 29, 2003 10:31 AM
Subject: Re: [ebxml-bp] [12/12/03]: BPSS Signals


> 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" <Monica.Martin@Sun.COM>
> To: "Boonserm (Serm) Kulvatunyou" <serm@nist.gov>
> Cc: <ebxml-bp@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" <Monica.Martin@Sun.COM>
> > >To: <Lars.Abrell@teliasonera.com>
> > >Cc: <ebxml-bp@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.Abrell@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.Abrell@TeliaSonera.com * +46 (0) 705 619080
> > >>>* Kilsgatan 4, Box 299, SE-401 24 Gothenburg, Sweden
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >
> > >
> > >
> >
> >
> >
> >
> >
> >
>
>