[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
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.
>
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]