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

["Yunker, John" <yunker@amazon.com>]

JJ I agree 100% that it is a best practice to only include information visible to all effected parties in the definition of the rules.  That the information is only visible to certain of the parties AFTER the business action completes does not detract from its usefulness in the definition.

-----Original Message-----
From: Jean-Jacques Dubray [mailto:jeanjadu@Attachmate.com] 
Sent: Tuesday, June 15, 2004 11:52 AM
To: Jean-Jacques Dubray; 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


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