Re: [ebxml-bp] ebXML Business Processes and Execution Summary For Today'sDiscussion

[Martin Sachs <msachs@cyclonecommerce.com>]

This is an excellent summary and starting point for going forward  I  have 
a couple of comments (MWS:) below.

Regards,
Marty

At 10:38 AM 11/10/2003 -0700, Monica J. Martin wrote:
>I've constructed a summary of the multiple discussions that have
>occurred surrounding execution and hope we can begin to provide some
>scoping in today's meeting (Monday, 10 Nov, 1 p.m. PST). Thank you to
>everyone that contributed to this thread and further inputs are welcome
>today or via the list.
>
>Where does execution fit for BPSS - what are the boundaries?
>================================================================================================================
>A Business Process Specification Schema (BPSS) instance is a computable
>representation of the interaction between two or more trading partners.
>The BPSS
>has design and run-time aspects.[1]  The BPSS describes the visible
>collaboration between the parties, not the binding or partner specific
>run-time systems.
>
>In the BPSS, the Business Service Interface (BSI) is the runtime
>software that can isolate the internal communications of a given legacy
>or other application
>from the collaboration model, and once built represent the party in a
>collaboration model. The BSI should be deployable into the run-time
>system, where the instance
>document can be used to configure it to execute and monitor the business
>process it describes.

MWS: This is just a point of clarification.  Since directly above, it 
states that the BSI is the runtime software, I think the above sentence 
should be: "The BPSS should be deployable into the run-time system,..."


>The BPSS technical specification can or will support:
>
>     * Business state (for business process and message exchange
>       choreography): Ensure state transitions are well formed and fully
>       defined.
>     * Businesss semantics [2]
>     * Business entity types
>
>[1] Provide sufficient support for binary and multi-party collaboration.
>[2] Those within the scope of BPSS or can be referenced from a normative
>source.
>
>Items to resolve:
>1. Difference between object and process state and how to marry/resolve
>2. Any visualization support
>3. Context support and where that lies
>4. How do business rules impact the transaction, state transitions, etc?
>5. Is a separate configuration document to link the Business Transaction
>Activity with some legacy system that would generate/consume the
>business documents needed?

MWS: The CPA (with extensions if necessary) should play the role of this 
configuration document.

>==============================================================================================
>Discussion Summary
>
>     * Lemmetty: BPSS-configured layer acts as a curtain between
>       organizations stage and backstage. BPSS describes what happens on
>       the (visible to partners) stage. Whatever is bound to the curtains
>       backstage, is not necessarily visible to others. Since BPSS is
>       shared among partners and they might have different
>       runtime-systems, any binding-information (which might be
>       partner-specific) should be in separate definition instance.

MWS:  As above, the CPA provides this kind of binding information.

>     * Yunker: 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".
>     * Webber: Question if context and capability should be placed in the
>       implementation layer (reference to BCM choice points).
>     * Tell: An efficient way is to attach "effects" to transactions. It
>       would be a huge step forward in term of creating a "business"
>       protocol if business semantics were to be found in transactions
>       etc. Just the name of and identified document types and
>       transaction types are not enough.
>
>Observations
>
>     * 11/4: Touches on visibility of the collaboration or specific
>       transactions for MPC.
>     * 11/6: Two parties need the capability to see and and dynamically
>       align/agree with underlying business logic (which will likely be
>       not apparent in the BPSS). How does this affect the business rules
>       that can impact/direct the collaboration steps and the states that
>       can/do occur?
>     * 11/6: Suggestion to add more support in BPSS for visual
>       diagramming. Is this a white paper vs. a specification requirement?
>     * 11/7: Need to include some understanding of Business Entity Types
>       in BPSS (identified in previous specification development) 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).
>
>==============================================================================================

*************************************
Martin Sachs
standards architect
Cyclone Commerce
msachs@cyclonecommerce.com