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

["Kenji Nagahashi" <nagahashi@fla.fujitsu.com>]

(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