[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: ebBP 2/7/2005: Updated Combined Summary of BSI-MSI
Monica: Please adjust the minutes to show that the BSI definition on Feb 4 is from the official ebXML Glossary, not from me. I do not concur with the definition since it does not seem to align with either BPSS or TA semantics of BSI. I do not want my name associated with the statement. It now becomes apparent that there are two (potentially 3 if the glossary is not fixed) conflicting definitions of BSI within ebXML. I highly recommend that you guys decide on a way to fix this if you concur that such is a problem. I am sure the architecture guys will agree that you all need to find a solution. Duane Monica J. Martin wrote: > This is an updated BSI-MSI summary based on all inputs up through > those proposed today 7 February 2005. Changes to our previously agreed > upon text are in UPPER CASE TYPE. Attribution is given to the section > fragments that have been changed. Additional references and three open > questions are provided at the end of the combined summary. Please plan > to attend our meeting tomorrow to discuss. Thank you. > > ============================================================================================================ > > Section 4: Language Overview > ================ > FROM: > The BSI is completely separate from the Message Service Interface > (MSI). In particular an MSI MAY be used without a BSI. A CPA, which > contains a reference to a ebBP definition serves as the basis for the > configuration of the BSI to enforce the protocol and semantics of the > ebBP definition, as depicted in Figure 1. > > TO: > The BSI is completely separate from the Message Service Interface > (MSI). They may effectively be used together even though the MSI MAY > be used without a BSI. > > The BSI is a logical definition for a party's actions, EXPOSED AS > BUSINESS SERVICES. IT MAY BE SEEN AS A LOGICAL SHARED > DEFINITION AT DIFFERENT NODES.[1] LOGICALLY, A BSI IS A PARTNER'S > IMPLEMENTATION OF THE SHARED DEFINITION OF BUSINESS STATES AND ACTIONS > RELEVANT TO A COMMON BUSINESS GOAL. IN THE CONTEXT OF EBXML BPSS, ONLY > THE SHARED BUSINESS PROCESS IS BEING MANAGED. > > IN EXECUTION, THE BSI USES THE CURRENT STATE OF THE BUSINESS PROCESS, > AS DEFINED IN THE BUSINESS COLLABORATION > MODEL, TO GUIDE [??DIRECT OR PRESCRIBE] ACTIONS AND REPORT THE STATE > CHANGES. THE EBXML BPSS DEFINES THE BSI > BEHAVIOR WITHIN THE BOUNDARIES OF THE SHARED COLLABORATION DEFINITION, > BUT DOES NOT DICTATE ITS TECHNICAL IMPLEMENTATION. [2] ITS REALIZATION > MAY BE ACCOMPLISHED BY USING OTHER SUPPORTING FUNCTIONS. [3] > > AS DESCRIBED IN THE EBXML BPSS TECHNICAL SPECIFICATION, THE BSI IS THE > LOGICAL SET OF TRANSACTIONS NECESSARY > TO ACHIEVE A COMMON GOAL. THE BSI BOUNDS THE BEHAVIOR OF A MSI IN THE > CONTEXT OF THE SHARED COLLABORATION DEFINITION. THE BSI ALSO PROVIDES > REQUIREMENTS TO THE MSI, SUCH AS QUALITY OF SERVICE (SUCH AS > NON-REPUDIATION, AUTHORIZATION, ETC) AND SERVICE CONFIGURATION > CAPABILITIES. > > A BSI IS, THEREFORE: > > * A DISCRETE SET OF BUSINESS PROCESS STATES (RESULTS OF BUSINESS > TRANSACTIONS) SHARED AND ALIGNED BETWEEN TRADING PARTNERS. > * A DISCRETE SET OF BUSINESS TRANSACTIONS. > * A DISCRETE SET OF TRANSITIONS BETWEEN BUSINESS TRANSACTIONS. > * THE BUSINESS RULES GOVERNING (1) THROUGH (3). [4] > > THE SET OF IMPLEMENTATION CHOICES, SUCH AS USE OF JAVA BEANS, WEB > SERVICES, ETC. THAT MAY DEFINE THE BUSINESS > SERVICES ARE NOT SPECIFIED NOR A PART OF THE BSI. THEY MAY COMPRISE > THE BUSINESS SERVICES THAT THE BSI UNDERSTANDS, LOGICALLY ENVELOPES > AND ABSTRACTS. [5] > > A CPA specifies actually the interface with access points defined by > the business process specification used. The CPA, which contains a > reference to an ebBP definition, serves as the basis for the > configuration of the BSI to enforce the protocol and semantics of the > ebBP definition OR, IN CERTAIN CASES, OVERRIDE SUCH RULES, as depicted > in Figure 1. [6] > > <<Implementer's note: The ebXML BPSS technical specification does not > specify how the BSI is implemented. For example, the BSI may be > enabled through a BSI-aware business application or through behavior > implemented as part of an MSI component. The business application may > produce the business signals that are sent (realized) by the Message > Service Handler.>> > > At a minimum, the BSI relates to the MSI in three ways: > > * Provide requirements to MSI. > * Constrain implementation of the MSI. > * Provide for auto generation of MSI. > > THE MSI SUPPORTS AND MAY ENFORCE THE BSI IN MANY WAYS, INCLUDING THROUGH: > > * MESSAGES THAT MAP TO BUSINESS TRANSACTIONS > * SIGNALS THAT ALIGN STATE > * BEHAVIOR UPON RECEIPT/NON-RECEIPT OF MESSAGES AND SIGNALS > * ENFORCEMENTS OF SECURITY CONSTRAINTS > > THE EBMS, CPA AND EBXML BPSS SHOULD ACT AS A REFERENCE SET TO DEFINE > THE MSI/BSI BEHAVIOR WITH A GOAL > TO ALLEVIATE HUMAN INTERVENTION. AT DESIGN TIME, THE MSI MAY EMBED > BSI BUSINESS RULES OR THE MSI AND BSI MAY COMMUNICATE IN EXECUTION. > [7] Design and deployment decisions may guide where an implementation > lies on this continuum. In the ebXML BPSS technical specification, > option 2 is recommended. As a design choice, the ebXML architecture, > and this specification, modularizes and separates these different > process and messaging functions. > > IN EXECUTION, AN IMPLEMENTATION (I.E. AN ENGINE) MAY HAVE A SPECIFIC > INTERFACE WITH A MSH AND ANOTHER DEFINED ONE TO DOMAIN-SPECIFIC > APPLICATIONS (SUCH AS BACKEND SYSTEMS), SERVICES OR OTHER ENGINES. [8] > BROADLY, THESE DEFINITIONS ARE CONSISTENT WITH THE EBXML TECHNICAL > ARCHITECTURE, V1.04.[9] WHERE THESE BOUNDARIES LIE, IRRESPECTIVE OF > HANDLERS OR INTERFACES, MAY BE A PRODUCT OF THE TRADING PARTNER DESIGN > CHOICES AND CONSTRAINTS, RATHER THAN A CONCRETE BOUNDARY OF SOFTWARE > COMPONENTS. [10] > > THE SHARED COLLABORATION DEFINITION, THAT INCLUDES THE BUSINESS > TRANSACTION SET(S), THE APPLICABLE BUSINESS TRANSACTION PATTERNS USED, > QUALITY OF SERVICE CAPABILITIES AND OTHER SERVICE CONFIGURATION > DETAILS, MAY > RESULT IN PROFILES RELEVANT TO A GROUP OF TRADING PARTNERS, INDUSTRY > OR DOMAIN. [11] > > Section 4.7: Core Business Transaction Semantics > Additional text proposed for the first paragraph or a second paragraph > after the first. > > FROM: > The ebXML concept of a business transaction and the semantics behind > it are central to predictable, enforceable commerce. It is expected > that any Business Service Interface (BSI) will be capable of managing > a transaction according to these semantics. > > TO: > The ebXML concept of a business transaction and the semantics behind > it are central to predictable, enforceable commerce. It is expected > that any Business Service Interface (BSI) will be capable of managing > a transaction according to these semantics. As the BSI is a logical > definition, design and deployment choices are not specified (See > Section 4). For example, the BSI may be instantiated or provide > requirements that guide or generate the MSI to react to specific > events defined in the business process. The MSI may interact with the > BSI, that recognizes the state of a business transaction. This may > enable the MSI to implement rules when specific steps occur. The > semantics defined in the ebXML BPSS technical specification enable the > BSI to constrain and guide design and deployment based on the business > transaction semantics. > > [1] Moberg > [2] Yunker > [3] Moberg > [4] Yunker > [5] Yunker > [6] Yunker > [7] Yunker > [8] Schlegel > [9] BSI = An ebXML collaboration that is conducted by two or more > parties each using a human or automated business service that > interprets the documents and document envelopes transmitted and > decides how to (or whether to) respond. [definition provided by > Nickull, 4 Feb 2005]. > [10] Martin > [11] Webber > > ============== > Additional references: > > * TC discussion 2/1: > > http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/event.php?event_id=6485&; > > (See Meeting Minutes attached to Calendar Event) > * Agreed upon definition prior to series of emails: > > http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/email/archives/200502/msg00012.html > > (3 February 2005) > * wd 06 technical specification (we have an update to be provided by > tomorrow): > > http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/document.php?document_id=11266 > > > ============== > Open questions: > 1. Where does the BSI sit? [Schlegel 2/4] > 2. If required, discuss BSI/MSI dependencies in greater detail and > determine if examples or follow-on documents that show reference > ebMS/CPA/BPSS dependencies for BSI and MSI. [Yunker 2/4] > 3. In the future, a BS[H] ideally (one day) present a standardised > interface (BSI) to the next layer which is the private process execution > engine (eg a BPM configured with a BPEL). The BSI is important to > address. [Capell 2/4] [note: This is scoped for post-v2.0. -Martin] > > > -- *********** Senior Standards Strategist - Adobe Systems, Inc. - http://www.adobe.com Vice Chair - UN/CEFACT Bureau Plenary - http://www.unece.org/cefact/ Adobe Enterprise Developer Resources - http://www.adobe.com/enterprise/developer/main.html ***********
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]