Re: [ebxml-iic] BPSS test scope issue

["Boonserm \(Serm\) Kulvatunyou" <serm@nist.gov>]

----- 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>

> 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>

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?
I need more explanation for the second bullet.
</serm1>

> 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>

> 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