Re: [ebxml-bp] [ebBP] Tell 6/14/2004: Business Contract Requirements for State Alignment

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

Hima,

Absolutely right!  Since the ebContext is XPath based - you are
working with a constrained environment - either specific
variables set to values - or XPath references that
are then referencing content in exchange transactions - this is
ebBP after all - not BPEL, eh?! ; -)

DW
----- Original Message ----- 
From: <Himagiri.Mukkamala@sybase.com>
To: "Jean-Jacques Dubray" <jeanjadu@Attachmate.com>
Cc: <anderst@toolsmiths.se>; <ebxml-bp@lists.oasis-open.org>; "Jean-Jacques
Dubray" <jeanjadu@Attachmate.com>; <martin.me.roberts@bt.com>;
<Monica.Martin@Sun.COM>; <nagahashi@fla.fujitsu.com>; "Yunker, John"
<yunker@amazon.com>
Sent: Tuesday, June 15, 2004 4:53 PM
Subject: RE: [ebxml-bp] [ebBP] Tell 6/14/2004: Business Contract
Requirements for State Alignment


>
>
>
>
> I agree with you that the "condition" evaluation
> can only occur on mutually(publicly)visible parameters.
>
> I'm assuming when we get to evaluatable rule logic
> syntax, we'll only deal with above mentioned requirements
> and not deal with a private event like "customer
> going to internal website to order supplies" as a
> precondition or beginsWhen event.
>
> -h
>
>
>
>              "Jean-Jacques
>              Dubray"
>              <jeanjadu@Attachm                                          To
>              ate.com>                  "Jean-Jacques Dubray"
>                                        <jeanjadu@Attachmate.com>,
>              15/06/2004 11:51          <Himagiri.Mukkamala@sybase.com>
>              AM                                                         cc
>                                        <anderst@toolsmiths.se>,
>                                        <ebxml-bp@lists.oasis-open.org>,
>                                        <martin.me.roberts@bt.com>,
>                                        <Monica.Martin@Sun.COM>,
>                                        <nagahashi@fla.fujitsu.com>,
>                                        "Yunker, John" <yunker@amazon.com>
>                                                                    Subject
>                                        RE: [ebxml-bp] [ebBP] Tell
>                                        6/14/2004: Business Contract
>                                        Requirements for State Alignment
>
>
>
>
>
>
>
>
>
>
> To be clear:
>
> I am all for providing unilateral validation rules (e.g. don't send this
> PO if it is not approved).
>
> I am also supporting the notion of assigning state to certain points of
> the collaboration (when this BTA begins we are in that state, when this
> BTA ends successfully, we are in that state, ...)
>
> But I believe it is dangerous to make the choreography of the
> collaboration dependent on preconditions (say there is a precondition on
> a cancel PO BTA that only one party can evaluate? Why expose it? Why
> make it part of the choreography? This is a private knowledge (at best
> make it part of the CPPP)) Wouldn't we be in the case where a party said
> I thought you could not cancel that PO while the other said it could.
>
> Jean-Jacques
>
> -----Original Message-----
> From: Jean-Jacques Dubray
> Sent: Tuesday, June 15, 2004 11:39 AM
> To: Himagiri.Mukkamala@sybase.com
> Cc: anderst@toolsmiths.se; ebxml-bp@lists.oasis-open.org;
> martin.me.roberts@bt.com; Monica.Martin@Sun.COM;
> nagahashi@fla.fujitsu.com; Yunker, John
> Subject: RE: [ebxml-bp] [ebBP] Tell 6/14/2004: Business Contract
> Requirements for State Alignment
>
> Again, the problem is a state alignment problem. There are two cases:
> 1) both parties can evaluate the precondition, in that case no problem
> the state is aligned (e.g. this collaboration will start a 12:00 noon
> every day)
> 2) only one party can evaluate the precondition (this collaboration can
> only start if the PO is approved). In that case you need to exchange a
> message (the PO) to align the state and give both parties the
> opportunity to evaluate the precondition. There is no precondition on
> that new initial BTA.
>
> The use of preconditions breaks the state alignment model that we have
> so carefully crafted. As such they cannot be part of the chorography
> definition.
>
> Jean-Jacques
>
> -----Original Message-----
> From: Himagiri.Mukkamala@sybase.com
> [mailto:Himagiri.Mukkamala@sybase.com]
> Sent: Tuesday, June 15, 2004 11:23 AM
> To: Jean-Jacques Dubray
> Cc: anderst@toolsmiths.se; ebxml-bp@lists.oasis-open.org;
> martin.me.roberts@bt.com; Monica.Martin@Sun.COM;
> nagahashi@fla.fujitsu.com; Yunker, John
> Subject: Re: [ebxml-bp] [ebBP] Tell 6/14/2004: Business Contract
> Requirements for State Alignment
>
>
>
>
>
> JJ,
>
> Begins/EndsWhen do control the choreography
> at the transaction level and collaboration level.
>
> BeginsWhen at a collaboration level would cause
> the collaboration to commence and at a transaction
> level cause the transaction to be initiated, assuming
> that there is'nt a "Transition" defined using
> "ConditionExpression" or "conditionGuard".
>
> -h
>
>
>
>
>
>
>              "David RR Webber"
>
>              <david@drrw.info>
>
>
> To
>              15/06/2004 10:13          "Jean-Jacques Dubray"
>
>              AM                        <jeanjadu@Attachmate.com>,
> "Yunker,
>                                        John" <yunker@amazon.com>,
>
>                                        <martin.me.roberts@bt.com>,
>
>                                        <Monica.Martin@Sun.COM>,
>
>                                        <anderst@toolsmiths.se>,
>
>                                        <nagahashi@fla.fujitsu.com>
>
>
> cc
>                                        <ebxml-bp@lists.oasis-open.org>
>
>
> Subject
>                                        Re: [ebxml-bp] [ebBP] Tell
>
>                                        6/14/2004: Business Contract
>
>                                        Requirements for State Alignment
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> JJ,
>
> Yes I concur - the regular guard conditions are just on the level of the
> exchanges themselves - and check those success / fail
> conditions within a BT.
>
> The begins/endsWhen are state conditions at the level of the BT - and
> control
> when the next / previous BT begins / ends.
>
> Thanks, DW
> ----- Original Message -----
> From: Jean-Jacques Dubray
> To: Yunker, John ; martin.me.roberts@bt.com ; david@drrw.info ;
> Monica.Martin@Sun.COM ; anderst@toolsmiths.se ;
> nagahashi@fla.fujitsu.com
> Cc: ebxml-bp@lists.oasis-open.org
> Sent: Tuesday, June 15, 2004 1:00 PM
> Subject: RE: [ebxml-bp] [ebBP] Tell 6/14/2004: Business Contract
> Requirements for State Alignment
>
>
>
>
> The key benefit here is the ability to associate/link a BPSS sematic
> node
> with both 1) its implementation and 2) its role in the
> business-agreement/contract layer.  How that is implemented with respect
> to
> a backend system event is not my concern, what is my concern is the
> semantic-definition that can be USED to implement a backend monitor.
>
>
> <JJ>If I understand this paragraph correctly, beginsWhen is not used in
> the
> sense of a "guard" (can only begins when the condition is true and other
> things have to happen before this guard flips its value), but rather in
> the
> sense of expressing a state (i.e. when this BTA begins, then we are in
> the
> "product delivered state" provided that there is a delivery date, ... Is
> that
> correct? In that case, it would mean that the beginsWhen and endsWhen
> have
> no influence on the choreography, they are really state representations
>
>
> </JJ>
>
>
>
>
>
>
>
>
> -----Original Message-----
> From: martin.me.roberts@bt.com [mailto:martin.me.roberts@bt.com]
> Sent: Tuesday, June 15, 2004 8:35 AM
> To: david@drrw.info; Monica.Martin@Sun.COM; anderst@toolsmiths.se;
> Yunker,
> John; nagahashi@fla.fujitsu.com; jeanjadu@Attachmate.com
> Cc: ebxml-bp@lists.oasis-open.org
> Subject: RE: [ebxml-bp] [ebBP] Tell 6/14/2004: Business Contract
> Requirements for State Alignment
>
>
> Hi,
>         I know I am not partaking much these days but on this subject I
> have some views.
>
>         beginsWhen and endWhen were effectively comments on the
> transaction
> in 1.01 and the CEFACT 1.1.  Moving away from this to show some other
> flow
> or usage needs to be very, very carefully thought through.  I would be
> unhappy to see that these are used as a back door event based solution.
> I
> know that is what they were aimed at originally, it is just that the
> implications of this are to make the processes more complex.
>
> Martin Roberts
> xml designer,
> BT Exact
> e-mail: martin.me.roberts@bt.com
> tel: +44(0) 1473 609785  clickdial
> fax: +44(0) 1473 609834
> Intranet Site :http://twiki.btlabs.bt.co.uk/twiki
>
>
>
> -----Original Message-----
> From: David RR Webber [mailto:david@drrw.info]
> Sent: 15 June 2004 15:29
> To: Monica J. Martin; Anders W. Tell; Yunker, John; Kenji Nagahashi;
> Jean-Jacques Dubray
> Cc: ebXML BP
> Subject: Re: [ebxml-bp] [ebBP] Tell 6/14/2004: Business Contract
> Requirements for State Alignment
>
>
> Monica,
>
> Not wanting to preempt discussion on Friday - but just wanting to throw
> out
> some technical ideas.
>
> What if we linked the signals to the begins/endsWhen conditionals on a
> BT?
>
> Just like with my proposal around linkage to context statements using a
> nameRefID - we could easily point to a named signal (it has that
> attribute
> already) and it would be either then boolean true or false.
> eg:  beginsWhen="#mysignal-Is-On"
>
> This still leaves how the signal itself gets set of course!  Seems like
> Dales post earlier may fit / hint into that category...since the only
> attribute in the signal right now is the URI - how does one actually
> turn a
> signal on?!
>
> If we can crack that "glue" then I believe we can provide
> what we need here.
>
> Am I also right in thinking that essentially used in this way the
> signals
> actually constitute the equivalent of an immediate "break" command so
> familiar in procedural languages to escape into/out of the current
> logical
> block.  In our case that is of course a BT.
>
> DW
>
> ----- Original Message -----
> From: "Monica J. Martin" <Monica.Martin@Sun.COM>
> To: "Anders W. Tell" <anderst@toolsmiths.se>; "Yunker, John"
> <yunker@amazon.com>; "Kenji Nagahashi" <nagahashi@fla.fujitsu.com>;
> "Jean-Jacques Dubray" <jeanjadu@Attachmate.com>
> Cc: "ebXML BP" <ebxml-bp@lists.oasis-open.org>
> Sent: Tuesday, June 15, 2004 1:53 AM
> Subject: [ebxml-bp] [ebBP] Tell 6/14/2004: Business Contract
> Requirements
> for State Alignment
>
>
> > Today's ebBP call surrounded how we ensure (as much as practical)
> > state alignment. Kenji Nagahashi proposed we provide additional
> > constraints on web services (top-down approach - business process to
> > web services).  We would like to more fully discuss the business
> > contract requirements related to: State alignment and business
> > signals.  Here are some of the questions that arose (from John Yunker
> > particularly):
> >
> >     * How do signals give you state alignment? How do we get certainty
> >       from a business perspective?
> >     * How does the contract layer use the state alignment will help us
> >       relate the special business timeouts to the technical signal
> >       receipt.BPSS provides a semantic to the contract layer.  The
> >       business level timeouts in addition to the protocol level have
> to
> >       be recognized.
> >     * How does the contract layer use the state alignment. This will
> >       help us relate the special business timeouts to the technical
> >       signal receipt. [1]
> >
> > The bullets above can form the agenda (subject to team input).  Any
> > member is welcomed to attend. Those expressing an interest today were:
>
> > Yunker, Dubray, Nagahashi and Moberg (and myself).
> >
> > You have indicated you would be available Friday and Monday (6/21).
> > Let's try, as discussed:
> >
> >     * 877 330 9868, international 909 472 3386, when prompted hit **,
> >       then passcode 09868.
> >     * Time: 9 a.m. PDT, 6 p.m. CET, 18 June 2004.
> >     * Agenda above.
> >
> > Thanks.
> > [1] Steve Capell, RedWahoo question.
> >
> >
> >
>
>
>
>