RE: [ebxml-dev] State alignment

[Jean-Jacques Dubray <jjd@eigner.com>]

Mike,

Since your email was in response to mine, here is what I would say. 

>>While I agree with these statements, I must also note that they also
point
>>out one of the more formidable problems that application vendors will
have
>>in supporting the BPSS.  Every application already has it's own state
>>machine.  
[JJ] Actually this is precisely why BPSS was designed the way it is
designed. I remember clearly introducing the group to the Pi-calculus
theory in the fall of 2000 (Someone from CommerceOne had pointed out
this theory to me in a different context). I recommend that you take a
look at it (here is a summary: http://www.ebpml.org/pi-calculus.htm 

This theory explains in great details what are the problems when two
state machine need to be synchronized and how to achieve it. The way to
do it is via a ... collaboration ! Far from creating a headache for
application vendor, we application bring them THE right solution with a
strong theoretical background to prove it.  

Overall, your argument about state alignment is totally misleading,
because if you want to integrate your processes with the one of your
business partners, you would need some kind of alignment. Maybe your are
like BPMI/BPML you don't believe that processes have any B2B touch
points. SO the question is what do you align it to? You publish your
"API", you align it to the "APIs" of all your business partners? Well
no, you define a collaboration that each partner can align with.

>>These state machines are usually organized around the point of
>>view of internal business processes (for example, many systems won't
let
>>you invoice without an order, or invoice without first indating that
the
>>ordered goods have been shipped).   Implementing a BPSS will require
one
>>to
>>map the states of these existing machines onto those specified in the
>>BPSS.  
[JJ] This is only if you assume that your ebXML infrastructure is
directly connected with your application. I have written many times
(http://www.ebpml.org/architecture.htm) , and I am sure I am not the
only one nor the first one, that in this case, you may want to use a
business process management systems to "adapt" the mismatch between
collaborations and internal business processes. This is in particular
why I have lobbied so much in BPMI to make "collaboration" a first class
citizen in the BPML metamodel. A more traditional EAI infrastructure
able to implement "integration scenarios" is also possible. 


>>So, added to the burden of mapping application data to UIDs (or EDI
>>data elements in our current world), vendors and/or end users have to
map
>>application states to BPSS process states.  That's fine so long as the
>>BPSS
>>states are uniform (like a defined dictionary of states), but if they
are
>>different then life gets very complicated (much more so than just
>>supporting both X12 and EDIFACT invoices).  
[JJ] If you read carefully what I have written, BPSS does not define
states in the sense of application states. BPSS define a collaborative
(peer-to-peer) message exchange represented as "states" for choreography
purposes. [I don't mean to confuse anyone, but you can also formally
demonstrate that a collaboration is a state machine, but this is
irrelevant for the synchronization of the state machines representing
each business partner. Furthermore this state machine does not have any
physical systems which supports it] 

Typically if you want to support a given collaboration, the work you
would have to do would be no different than the one you already do for
application integration. This is why people often refer it to B2B
integration. So the typical activity that you will need to do is to
match these message exchange with an (or several) application APIs (or
web services - http://www.ebpml.org/showcase.htm)

The BSI (by enforcing the BPSS definition) adds a lot of value to the
applications by preventing an application to issue a message to a
business partner that we have detected will automatically generate an
error. Of course, it also enforces that a message sent by your business
partner will not be passed on to your application if it detects any
error. In addition some exception may be forwarded to your application
(Acceptance Ack). 


>>specifies a state that can't be easily matched to an internal
application
>>state, then either application modifications are required in order to
>>support the state or the user is forced to intervene and handle that
state
>>"out-of-band" as a manual exception.
>>
>>And about getting "out of synch" with your business partners - I'm
sure
>>that there are a few people who have this problem and for them I'm
sure
>>that it is a big problem.  However, most application systems I've
worked
>>with that support e-Business in any serious fashion are already
configured
>>to avoid this type of thing.  I don't see it as a major concern for
most
>>users.
[JJ] I can assure you that if you are a large company which processes
100,000 to 1,000,000 "events" per day (most of these "events" would find
their origin from a B2B message exchange), the last thing you want to do
is to get out of synch. You would use several FTEs just to deal with it.

If you are a small company (I had a small business of 5 people in the
past selling to companies worldwide), I can assure you that the last
thing you want to do is to deal with errors and exceptions in my orders
and invoices. 

So, as you probably missed it, BPSS is about making B2B message exchange
as reliable as withdrawing (or depositing) money from your ATM machine.
Could you do it without guaranteed state synchronization? You give us
the answer...

>>
>>This leads me to the conclusion that while the BPSS and the UMM upon
which
>>it is based may be valuable tools for documenting and agreeing on
business
>>processes (for those who find ROI in using them), I see little utility
for
>>them in the near future for actually automating the execution of
business
>>processes.
[JJ] It is only modeling which can lead to automation, or minimize user
intervention. The WebMethods of the world can show you how this "magic"
can happen since you don't seem to be a believer.

Jean-Jacques Dubray
Chief Architect of the Eigner PLM product line (www.eigner.com)
Proud to be an ebXML contributor.