Re: [ebxml-bp] BPSS executability and where it ends

["David RR Webber" <david@drrw.info>]

Kenji,

I noticed this previously from your earlier posting.

The solution to this I am seeing is the OASIS BCM TC
ChoicePoints approach.

Basically the need is to provide context driven linking
and switching - and for those points within the BPSS
flow to be able to key off that.

Since I'm leading the ChoicePoint definition work for
BCM I'm right now looking to build up usage cases -
so that we can move this forward.

What I like about the ChoicePoint approach is that
it is re-using existing technologies in a smart way -
and providing an API and XML bindings - to
accomplish the task required.

So we can potentially implement something very
rapidly.   I'm planning to share more with people
shortly (since Monica just called for items for
potential liaisons - this is certainly a clear area).

In the meantime - people can check out the
Appendix B Specification available for download
from the OASIS BCM TC area - and also the
PPT on ChoicePoints presented at the DAMA
Conference at:

 http://www.businesscentricmethodology.com

All input / thoughts gratefully received.

Thanks, DW

----- Original Message ----- 
From: "Kenji Nagahashi" <nagahashi@fla.fujitsu.com>
To: <ebxml-bp@lists.oasis-open.org>
Sent: Monday, November 10, 2003 3:50 PM
Subject: RE: [ebxml-bp] BPSS executability and where it ends


> (This is actually a follow-ups for messages from John and JJ, but I
couldn't
> put this in the thread, as stragely I'm not receiving ebxml-bp emails...)
>
> This is very interesting. I have been working on the same concept of
> describing business process.
> Throught the in-depth analysis of RosettaNet PIPs, I found it is difficult
> to describe real-world business processes by message exchanges.
> JJ wrote it is not completely impossible to do this BPSS 1.01, but I
observe
> some pains there.
> "Invoice_is_paid" can be defined by a condition on a message for simple
BPs,
> but it is not always the case. If you think of multiple payments for an
> invoice, you can't simply define "Invoice_is_paid" on a message. You have
to
> calculate a sum of all the payments to tell when an invoice is payed in
> full. This requires the concept of "business object". It seems for me that
> message exchanges are the result of state change of those business
objects.
> And also I looked into a supply-chain business process called VMI, and
found
> it has an step of sending exactly the same message to multipe partners.
> Message centric approach is not well-suited for describing this kind of
> multi-party business processes.
>
> (I will write more on this...)
>
> Kenji
>
> John Yunkder wrote:
>
> This is an area that Business Entity Types was supposed to partially
> address, by allowing the BPSS to reference named states of business
objects
> (e.g. Shipment is Delivered), and then layering the definition of
> "Delivered" (rule expression) in the business agreement (being addressed
by
> UBAC).
>
> Note that you could still put the BET state expression on the BPSS
> transitions (e.g. Invoice.is_Paid AND Product.in_Shipment AND
> Shipment_is_Delivered), and provide an element in the BPSS where the
states
> could have their complete definition (e.g. < 5% scrap).
>
> By allowing conceptual "business" state to guard the transitions, and then
> allowing both standard and partner specific definition of those states, we
> could truly extend the BPSS to be "business process" and not just "message
> exchange choreography".
>
> John
>
>