[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ebxml-bp] ebXML Business Processes and Execution Summary For Today'sDiscussion
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]