John,
This is definately in line with my thinking -
but here's a further detail.
I believe its cleaner to have the semantic
expression merely state some
true/false conditional that is to be evaluated
- this conditional then has
a plain language name that conveys the decision
being made.
This avoids any need for expression language
beyond the simple - OR /
AND linkage terms. So in your example it
simplifies to just:
"Product-is-delivered"
and then in the context mechanism - you can
test for delivery date and
delivery signature using XPath expressions
against the actual
confirming response received - using the
XML <condition ..... />
elements to capture those details in the
ebContext associated with
the binary collaboration.
This way - implementers can choose their own
language toolset to
parse the ebContext XML and those XPath
expressions, and the
confirming response transaction (could be EDI, XML, other) - and
then indicate to the BPSS processor by
setting "Product-is-delivered"
true/false.
This I hope does what is required here -
provides the means to
define semantically the BT level control -
while allows us to use
XPath as the expression syntax.
Note: the problem with using
"exists(delivered-date)" etc, is an
implementer has no way of knowing how to
actually make
that test work - and against what
content? Using XPath
solves that for us.
The only remaining piece to the puzzle is the
magic around
setting the Product-is-delivered flag
itself. Obviously that's
a BSI level item potential.
Right now - we can simply not worry about
it - since
implementers can easily declare an in-memory
indicator to
track that for the BPSS instance - and use
their own means
to update it.
But the key is that there is a direct link
between that flag
and the ebContext XPath expressions that do the
actual
work.
One further point
<snip>
Current BPSS does not have any method for linking the
definition-of-business-event-having-occurred. It is critical that BPSS
transitions occur immediately once a business action is complete, since the
owner of the event beginning the next transaction almost always rests with
the originating-party of the next transaction.
</snip>
Agreed - and I believe the begins/endsWhen
mechanism - functioning as a signal achieves what we need here.
We simply need to state in the specification
that that is the behave - that these signal conditions - via
the
ebContext mechanism work as immediate
interrupts - eg - when a transaction is exchange - if
useContextInstance is set to "true" for the BT
step - then conditions are tested - and binary collaboration
processing of BT flow then procedures accordingly.
Hope that is clearer?
Thanks, DW
----- Original Message -----
Sent: Tuesday, June 15, 2004 12:09
PM
Subject: RE: [ebxml-bp] [ebBP] Tell
6/14/2004: Business Contract Requirements for State Alignment
What I am concerned about is not the
technical-event linking, but more the semantic linking of the business
drivers.
Current BPSS does not have any method for linking the
definition-of-business-event-having-occurred. It is critical that
BPSS transitions occur immediately once a business action is complete,
since the owner of the event beginning the next transaction almost always
rests with the originating-party of the next transaction.
What I
want to put in the beginsWhen is
"name='product-is-delivered',
expression='exists(delivered-date) and
exists(delivery-signature)'". This is so there can be
a discrete linkage of the business semantic to the process
execution.
This fits well with David's idea of named context, but
also can easily be expressed using the same syntax as the transition
guards.
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.
Thanks!
John
-----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.
>
>
>