[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: ebBP 2/7/2005: BSI-Message Service Interface Updated-2 Summary
This is an updated-updated BSI-Message Service Interface summary based on all inputs up through those proposed late as of 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 four open questions are provided at the end of the combined summary. Please plan to attend our meeting tomorrow to discuss. Thank you to Duane Nickull for his suggestions. Regards. ============================================================================================================ Section 4: Language Overview ================ FROM: The BSI is completely separate from the Message Service Interface. In particular an Message Service Interface 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: <<deleted and moved first paragraph>> 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 <<MAY>> BOUND THE BEHAVIOR OF A MESSAGE SERVICE INTERFACE IN THE CONTEXT OF THE SHARED COLLABORATION DEFINITION. THE BSI ALSO PROVIDES REQUIREMENTS TO THE MESSAGE SERVICE INTERFACE, SUCH AS QUALITY OF SERVICE (SUCH AS NON-REPUDIATION, AUTHORIZATION, ETC) AND SERVICE CONFIGURATION CAPABILITIES. <<The LOGICAL BSI MAY BE ASSOCIATED WITH THE MESSAGING COMPONENT. The BSI MAY BE completely separate from the Message Service Interface (WHICH IS ALSO ANOTHER ABSTRACT BOUNDARY). [4] They MAY effectively be used together. Or, the Message Service Interface MAY be used without a BSI.>> 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). [5] THE SET OF IMPLEMENTATION CHOICES, SUCH AS USE OF JAVA BEANS, WEB SERVICES, ETC. THAT MAY DEFINE THE BUSINESS SERVICES ARE NOT <<SPECIFIED. [6] 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. [7] Implementer's note: The ebXML BPSS technical specification does not specify how the BSI is implemented. For example, the BSI <<CONCEPTS>> may be enabled through a BSI-aware business application or through behavior implemented as part of an Message Service Interface component. The business application may produce the business signals that are sent (realized) by the Message Service Handler. At a minimum, the BSI <<MAY>> relates to the Message Service Interface in three ways: * Provide requirements to Message Service Interface. * Constrain implementation of the Message Service Interface. * Provide for auto generation of Message Service Interface. THE MESSAGE SERVICE INTERFACE <<MAY SUPPORT AND 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 <<MAY>> ACT AS A REFERENCE SET TO DEFINE THE MESSAGE SERVICE INTERFACE/BSI BEHAVIOR WITH A GOAL TO ALLEVIATE HUMAN INTERVENTION. AT DESIGN TIME, THE MESSAGE SERVICE INTERFACE MAY EMBED BSI BUSINESS RULES OR THE MESSAGE SERVICE INTERFACE AND BSI MAY COMMUNICATE IN EXECUTION. [8] Design and deployment decisions may guide where an implementation lies on this continuum. In the ebXML BPSS technical specification, <<CONSTRAINTS OF THE BSI CONCEPTS ARE RECOMMENDED FOR ANY MESSAGING SERVICE INTERFACE. 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. [9] WHERE THESE <<LOGICAL>> BOUNDARIES LIE <<WHEN IMPLEMENTED>>, IRRESPECTIVE OF <<ACTUAL>> 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. <<THE>> Business Service Interface (BSI) <<MAY 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 Message Service Interface to react to specific events defined in the business process. The Message Service Interface MAY interact with the BSI that recognizes the state of a business transaction. This may enable the Message Service Interface 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] ebXML Messaging Service, v2.0, definition of Message Service Interface: An abstract service interface applications use to interact with the MSH to send and receive messages and which the MSH uses to interface with applications handling received messages (Delivery Module). [6] Yunker [7] Yunker [8] Yunker [9] Schlegel [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/Message Service Interface dependencies in greater detail and determine if examples or follow-on documents that show reference ebMS/CPA/BPSS dependencies for BSI and Message Service Interface. [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] 4. Do we cohere ebXML Glossary definition, and other understandings about BSI and Message Service Interface? [Nickull, 2/7]
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]