[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ebxml-bp] ebBP 2/1/2005: Descriptive Text MSI-BSI Relationship
We now have our verbiage unless I hear otherwise from anyone in the group. Thanks for the feedback, John and to everyone for the breadth and clarity in yesterday's call. Regards. ================= 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. 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, as depicted in Figure 1. The ebXML BPSS technical specification does not specify how the BSI is implemented. <<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: 1. Provide requirements to MSI. 2. Constrain implementation of the MSI. 3. Provide for auto generation of MSI. 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. 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]