[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ebxml-iic] BPSS test scope issue
Boonserm (Serm) Kulvatunyou wrote: >I think I understand your point about "different events happen at different >level". But I still can't agree with the substantive notion even if failure >occurs. I think that the BSI should be able to rollback the business level, >if any failure occurs in the system level. I think this substative notion >can mess up businesses. If the responder does not receive the last >acceptanceAck, it can't be certain that its response has reached the >business level (hence creating binding, etc.), although it has received the >receiptAck. > mm1: Several people have questioned this, and received quite a bit of pushback from some CEFACT players. I've cc: JJ Dubray in case he wishes to respond back as well. > >- serm > >----- Original Message ----- >From: "Monica J. Martin" <monica.martin@sun.com> >To: "Boonserm (Serm) Kulvatunyou" <serm@nist.gov> >Cc: <ebxml-iic@lists.oasis-open.org> >Sent: Wednesday, July 16, 2003 11:14 PM >Subject: Re: [ebxml-iic] BPSS test scope issue > > >Boonserm (Serm) Kulvatunyou wrote: > > > >>----- Original Message ----- >>From: "Monica J. Martin" <monica.martin@sun.com> >>To: "Boonserm (Serm) Kulvatunyou" <serm@nist.gov> >>Cc: <ebxml-iic@lists.oasis-open.org> >>Sent: Wednesday, July 16, 2003 4:15 PM >>Subject: Re: [ebxml-iic] BPSS test scope issue >> >> >>Boonserm (Serm) Kulvatunyou wrote: >> >> >> >> >> >>>The question is "are we testing the whole BSI?", since earlier Jacques >>>calls this BPSS testing as BSI testing. From the review of BPSS >>>(quoted below), it seems that BSI is assumed to cover the all the B2B >>>Collaboration management (which implies CPP and CPA as well). So I >>>think that if we were to focus the testing on BPSS Spec only we should >>>decompose the tests into groups and these tests won't cover the whole BSI. >>> >>>As I mentioned in the con call, BPSS spec divides the interop >>>requirements into Biz Trax and Biz Coll levels. And as of version >>>1.05, only Biz Tranx level is required. >>> >>> >>> >>> >>> >>mm1: BinaryCollaboration is still a CollaborationActivity, and a key >>functional element within BPSS. Please explain why you feel Business >>Collaboration is not 'required.' >> >><serm1> Monica, I concur with you. I just quoted this from the BPSS spec. >>See line 1879. Anyhow, I think it makes sense to start the test from the >>Runtime Transaction Semantics and Runtime Collaboration Semantics. >></serm1> >> >> >> >mm2: Iterative, I understand. > > > >> >> >> >>>The question is then (I think this is also Monica question) how we >>>should factor the MSH related parameters (e.g., tamper proof, >>>authorization required, etc.) into these interop requirements. Do we >>>care about these at all or we group these parameter as another set of >>>(vertical) interop requirements (between BSI and MSH) or we should >>>profile these parameters. >>> >>> >>> >>> >>> >>mm1: You have to realize these values occurs at different levels with >>different assumptions, albeit I agree there could be a dependency or >>assumption about their relationship (business vs. system). A prime >>example of this difference occurs in providing confidence that a Receipt >>Acknowledgement (and possibly an AcceptanceAcknowledgement - hot issue >>thought) has been received back from the Requester because it is >>required by the Responder. At the system level, errors occur if it is >>not received. However, at the business level, a warning may be issued >>and the process completes successfully due to business rules that >>dictate it is non-substantive. >> >><serm1> This business rules (I would rather call it Transaction Semantics) >>does not make sense to me at all. If a requester sends a Process PO and >>everything is okay in the requesting activity. Then the responder sends >> >> >back > > >>an Accept PO which never reaches the Requester Business so no receiptAck is >>sent back to the responder. How can the responder assume that the response >>is substantive??? I would expect the Requester to end the collaboration >> >> >with > > >>a Protocol fail and the Requester may want to start the same Process PO >> >> >with > > >>somebody else because he can't be certain that the PO has been processed. >></serm1> >> >> >> >> >mm1: I can send you the Protege drawings to illustrate. I did not say >the condition was that the Accept PO failed. All things being equal >(and successfuly to a point), I said that the Requester was to send a >ReceiptAck and AcceptAck to the Responder. If the Response is received, >and the Requester is, per business rules, to send the ReceiptAck and >AcceptAck (mostly the first) to the Responder, and doesn't what >happens? See my notes above. Of course, if there are problems, failures >occur. That was not my point. My point is that different events happen >at different levels. > > > >>I would suggest we approach this in several ways: >> >> * Content validation (valid values exist) against business rules >> required >> * Interaction >> o Business >> o System (may equate to your BSI/MSH interaction scenario >> >><serm1>I think I agree with the first bullet. However, for scoping purpose >> >> >I > > >>think the content validation done here should only be as part of business >>rules ascribed within the BPSS instance, i.e., w.r.t specified schema, >>specificationElement, and the isPositiveResponse parameters (not the whole >>content semantics). Do you agree with this? >> >> >> >mm1: That's a start. > > > >>I need more explanation for the second bullet. >></serm1> >> >> >> >> >mm1: You are trying to decide the scope of the test activities as they >relate to BPSS and its interaction/relationship/etc to other >functionality. As to my point on business level vs. messaging level >actions, we have business failures and actual errors that occur in the >MSH. Does that make sense? > > > >> >> >>>My feeling is that the second option is a good option b/c 1) these are >>>business/scenario specific requirements 2) dependent on MSH 3) they >>>are not indicated as requirements in the BPSS spec (see section 7.6 >>>and 7.7), and 4) these parameters do not directly effect the success >>>of a tranx/coll, they indicate the necessities to collaborate, i.e, >>>the collaboration wouldn't even start if one partner does not have >>>those required capabilities. >>> >>> >>> >>> >>> >>mm1: See above. >> >> >> >> >> >>>In conclusion my thougt is to decompose the BPSS test requirments into >>> >>>1 - Biz Tranx level state management >>> >>>2 - Biz collaboration level state management >>> >>>3 - BSI-MSI interoperability. >>> >>>I am not sure about its interaction with CPPA spec. >>> >>> >>> >>> >>> >>mm1: There will be similar dependencies with CPP/A (although on the side >>of the CPP/A for the BPSS). >> >><serm1> My question is whether it is okay to do not concern about CCPA >> >> >right > > >>now as we are writing test requirement for the BPSS? >></serm1> >> >> >> >> >mm1: As I said, the CPP/A uses the BPSS in the process specification. It >may be practical to start with the limited scope you propose. > > > >> >> >>>Quotes from BPSS spec: >>> >>>Line 620 BPSS - The ebXML Business Process Specification Schema should >>>be used wherever >>> >>>ebXML compliant software is being specified to execute Business >>>Collaborations. >>> >>>The generic term for such software is a Business Service Interface (BSI). >>> >>>The ebXML Business Process Specification Schema is used to specify the >>> >>>business process related configuration parameters for configuring a BSI to >>> >>>execute these collaborations. >>> >>>Line 631 of BPSS - Run-time transaction and collaboration semantics >>>that the ebXML >>> >>>Business Process Specification Schema specifies and the Business >>> >>>Service Interface (BSI) is expected to manage. >>> >>>Line 672 of BPSS - Guided by the CPP and CPA specifications the >>>resulting XML document then >>> >>>becomes the configuration file for one or more Business Service >>>Interfaces (BSI), >>> >>>i.e. the software that will actually manage either partner’s >>>participation in the >>> >>>collaboration. >>> >>>*** These indicates that BSI scope also includes CPP/CPA >>>- Serm >>>New! NIST Testbed Web Site - http://www.mel.nist.gov/msid/oagnisttestbed/ >>>-------------------------------------------------------------------------- >>> >>> >>> >>> >>------ >> >> >> >> >>>Boonserm (Serm) Kulvatunyou, Ph.D. >>>Guest Researcher >>>Manufacturing System Integration Division. >>>National Institute of Standards and Technology >>>On Assigment from Oak Ridge Associated Universities >>>100 Bureau Dr. MS 8260 Gaithersburg MD 20899-8260 >>>phone: 301-975-6775, fax: 301-975-4482 >>>mail: serm@nist.gov <mailto:serm@nist.gov>, http://serm.ws >>> >>> >>> >>> >> >> >>You may leave a Technical Committee at any time by visiting >> >> >http://www.oasis-open.org/apps/org/workgroup/ebxml-iic/members/leave_workgro >up.php > > >> >> >> > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]