[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ebxml-bp] [ebBP] Tell 6/14/2004: Business Contract Requirements for State Alignment
John,
I think in this email and your prior one - about "Those who are simply
choreographing transitions between actions (services / transactions) will
not use these definitions, those who are building enforceable collaborative
extended-enterprise-operations will."
Is saying the same thing as I was noting from the technical side - eg -
Simple BT with just guards on succeed / fail is fine for
simple transitions. Those needing water-tight fully enforceable
collaborations - will be using ebContext and CAM to lock
down all details about their transactions.
What is *very* important again about that - is that you only have to expose
what you want
to for scrutiny in XML as rules. Eg. I may have my own internal checks in a
CAM template
that I do *not* share with all partners - all they see is the
"document_failed_tests" in the
BTA - endsWhen="document_failed_test" level.
But again the important thing is that the flow revolves around the BTA
level - and may then
have a subsequent Fork - but this branching does *not* occur at the
individual interaction level.
This is a very-Prologesque way of building decision logic - with fully
deterministic steps - and
single entry and exit paths. It builds very reliable and predictable
declarative process flows.
DW
----- Original Message -----
From: "Yunker, John" <yunker@amazon.com>
To: "Jean-Jacques Dubray" <jeanjadu@Attachmate.com>;
<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>
Sent: Tuesday, June 15, 2004 2:57 PM
Subject: RE: [ebxml-bp] [ebBP] Tell 6/14/2004: Business Contract
Requirements for State Alignment
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.
>
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]