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