Re: [ebxml-bp] State Alignment and Web Services

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

Kenji,

OK - good clarification.  I think V2 can support the RosettaNet
example by allowing 'pending' as a return state - and then
the beginsWhen / endsWhen can be controlled using
the new variable mechanism with expressions that check
for the conditions between each BTA.

Since a guard condition checks for just succeed or
failure, you would need to setup a signal for the pending,
but of course - if you look closely - that signal can have
a transaction associated with it - so not a problem - as with
the RosettaNet case.

Since you talk about this "happening several times" - there
must be some kind of "fail" condition - that causes the
whole to re-start again from the top.  That would obviously
need to be "linking and switching" logic that resides
above the BPSS - in your implementation layer - that
causes the BPSS to be initiated again (possibly with
different requirements) to attempt a second or third time.

Perhaps we could model the appropriate PIP using
the new BPSS model I have to see how this can
all be represented?

Thanks, DW

----- Original Message ----- 
From: "Kenji Nagahashi" <nagahashi@fla.fujitsu.com>
Cc: "ebXML BP" <ebxml-bp@lists.oasis-open.org>
Sent: Friday, July 16, 2004 5:26 PM
Subject: Re: [ebxml-bp] State Alignment and Web Services


> Hi
>
> Sorry it was a slip of the finger to write "transport level". I meant
> "pending" is not part of BT.
> RosettaNet communicates "pending" through responding action, not through
> signal.
>
> Buyer sends purchase order request to seller, and the seller sends
> response message back with
> line item status set to "pending", thus completing the first BT (PIP).
> Later the seller initiates another BT to notify the buyer with new value
> in line item status -- either positive or negative confirmation, or even
> "pending" again. This could occur many times.
>
> I found some people see this modeling inconvenient and wanted to pack
> those multiple transactions into one BT,
> which is not possible with current BPSS. It might have something to do
> with David's point.
>
> Is anybody really interested in this example?
>
> Kenji
>
> David RR Webber wrote:
>
> > Kenji,
> >
> > Yes - the 'pending' is part of the BTA.   I guess in the
> > case of a distributor - it confirms that an attempt is
> > being made to find source(s) for product(s) requested.
> >
> > In that sense its a binding attempt to provide that,
> > and as you say - the answer could be - 'no source found'.
> >
> > Thanks, DW
> >
> > ----- Original Message ----- 
> > From: "Kenji Nagahashi" <nagahashi@fla.fujitsu.com>
> > Cc: "ebXML BP" <ebxml-bp@lists.oasis-open.org>
> > Sent: Thursday, July 15, 2004 6:43 PM
> > Subject: Re: [ebxml-bp] State Alignment and Web Services
> >
> >
> >
> >>Hi,
> >>
> >>This "pending" sounds like business level semantics, which should not be
> >>handled at the transport level.
> >>I can provide an example from RosettaNet which supports such "pending"
> >>status response. While the response message itself is legally binding,
> >>but you can say "no" later in update message.
> >>There might be a confusion about "legally binding". "legally binding"
> >>means that you're liable for what you said in the message ("pending" in
> >>this case), not for selling something no matter what your downstream
> >>supplier say...?
> >>
> >>Kenji
> >>
> >>David RR Webber wrote:
> >>
> >>
> >>>Monica,
> >>>
> >>>I believe this came out of a scenario that Anders described - where
> >>>he want to Ack the RFQ - but not confirm it until downstream suppliers
> >>>had responded.
> >>>
> >>>Therefore 'pending' was offered as an additional status.  Anders also
> >>>wanted to make sure that the signal was *not* a legally binding
> >>>response - hence 'pending' again avoids that connotation.
> >>>
> >>>It all made sense to me at the time - and I included this in the
> >>>XML example I posted on signals - along with the additional
> >>>two attributes - (BTW - signalType - agree that is not needed -
> >>>and can be deferred to V3).
> >>>
> >>>Thanks, DW
> >>>
> >>>
> >>>
> >>>>mm1: David, I do not recall that we defin3ed a pending status in the
> >>>>special sessions. Dale, can you confirm please. Thanks.
> >>>>
> >>>>
> >>>
> >>>
> >>
> >
>
>