OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-iic message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ebxml-iic] BPSS test scope issue


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.

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