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