ebBP 2/3/2005: Minor Update to Descriptive Text MSI-BSI Relationship

["Monica J. Martin" <Monica.Martin@Sun.COM>]

Minor update (Thanks to Hima Mukkamala, for the details): Change is 
designated by [add]...[end-add].

Thanks.

> =================
> 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.  [add] The use of the 
> MSI for a particular business interaction is constrained by the BSI 
> based on the characteristics defined in the business process 
> definition used. [end-add] 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.
>
>