Re: Subject: RE: eBTWG Proposal BPSS Revision Project 0.3 DRAFT

[bhaugen <linkage@interaccess.com>]

Timothy,

May I  please quote you at length in every possible forum
and maybe turn your message into a rap and/or pop song?

You have said what I have been trying to say much much
better than I could.  Thank you thank you.

In ebXML v1.0 there were two different BP groups,
the BPSS group and a CC-BP-Analysis group.
The analysis group was trying to do simplified
worksheets and business process editors for
business analysts.  The ebTWG Collaboration Patterns
project is trying to continue the same work.
We want to be able to define declarative business
collaboration defintions that can generate or map to
BPSS and other executable choreography models.

Pi-calculus is wonderful, I'm studying it, but I don't
think I can shove it down my business analyst's throat.
(I'd prefer to avoid it myself, if the truth be told...)

Thanks again,
Bob Haugen

From: Collier, Timothy R
> I think what is being discussed here is clearly a focal point for
> determining the direction of BPSS, and possibly its future.  Who is the
> intended user of BPSS?  Is it a business analyst, who wants to model their
> activities in a manner close to the logical business process? Or, is the
> user an implementer who needs to model a specific solution?  Their needs
are
> quite different.  For the analyst, they will want the ability to model
more
> of a state diagram approach, where the entire "manage purchase order"
model
> is depicted, for example.  Including request purchase order, some number
of
> optional modify purchase order, some number of optional query purchase
> order, as well as ship, and cancel purchase order.  All of these
activities
> should be expressible as part of the same model, in a logical (but not
> necessarily executable) model.
> In an executable model approach, where the workflow specifications
> are starting to crop up (WSFL, XLANG, ...), the user is constrained to an
> edge directed, acyclic, pi-calculus based model.  You cannot in these
> approaches model larger granularity activities like manage purchase order.
> This is where problems like prohibiting transition to self force the user
of
> the model to model their system in ways that are not in keeping with what
is
> really happening at the business level.  They must think like a
programmer,
> and make sure all of the activities are deterministic.
> I am not saying one approach is right or wrong, what I am trying to
> point out is - if BPSS is going to go down the path of being executable,
and
> compete head on with the web services specifications, it should do so only
> after clearly understanding who their customer is and what need it is
> addressing.
>
> Tim