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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-bp message

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


Subject: Re: [ebxml-bp] RE: [ebBP] [ebxml-iic] Scripting of Test Cases (Process Concepts)


Monica,

OK - see attached PPT slide.

Actually the table is separate from this item.

The table provides a neutral way for a transport
layer to inform the BPSS that a condition has
occurred as a result of a BT action and what
that condition is.

That said - most of the time this notification
will be a result of receiving a specific indication
response, or not receiving same (timeout).

Therefore you need to link the guard condition
to the associated interaction item.

The PPT slide attached has this called out.

Thanks, DW

----- Original Message ----- 
From: "Monica J. Martin" <Monica.Martin@Sun.COM>
To: "David RR Webber" <david@drrw.info>
Cc: "Jacques Durand" <JDurand@us.fujitsu.com>; "ebXML BP"
<ebxml-bp@lists.oasis-open.org>; "Michael Kass" <michael.kass@nist.gov>
Sent: Wednesday, May 26, 2004 1:20 PM
Subject: Re: [ebxml-bp] RE: [ebBP] [ebxml-iic] Scripting of Test Cases
(Process Concepts)


> Can you attach more explanation to this table in line with your question
> about associating guard conditions to specific transitions, and the use
> of a name?
>
> Thanks.
>
> > Webber: Jacques,
> >
> > Dale and I talked about this last week - and creating a table of these
> > for the BPSS V2 specification.  We have specific names for these
> > boundary conditions.  The transport layer should signal the Outcome to
> > the named guard for the interchange condition test. Here's my first
> > take at this:
> >
> >
> > * Condition *
> >
> >
> >
> > * Outcome *
> >
> >
> >
> > * Notes *
> >
> > isConfirmReceived
> >
> >
> >
> > timeout
> >
> >
> >
> > false
> >
> > isRequestAcceptanceFailure
> >
> >
> >
> > invalid
> >
> >
> >
> > true
> >
> > isPositiveResponse
> >
> >
> >
> > protocol failure
> >
> >
> >
> > false
> >
> > isBusinessSuccess
> >
> >
> >
> > business problem
> >
> >
> >
> > false
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > isPositiveResponse
> >
> >
> >
> > succeed
> >
> >
> >
> > true
> >
> > isBusinessSuccess
> >
> >
> >
> > succeed
> >
> >
> >
> > true
> >
> > isConfirmReceived
> >
> >
> >
> > succeed
> >
> >
> >
> > true
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Also - I've attached the JPG of the model I'm using to verify BPSS V2.
> >
> > The Interchange Profiles have various transport characteristics, and
> > again these tally with things like "timeout" - setting the boundary
> > conditions when this happens (see far right side of the model).
> >
> > I also raised the issue that the guard condition should be associated
> > with an interchange to make it clear when to apply what.  Again the
> > model illustrates this in the main activity part of the diagram.
>
>
>

BPSS-guard-linkage.ppt



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