OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-bp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: ebBP 2/1/2005: Descriptive Text MSI-BSI Relationship


Today we discussed the MSI-BSI relationship and I have attempted to 
capture the discussion in revised text from Section 4 Language Overview 
and Section 4.7 Core Business Transaction Semantics:

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 boundary for a party. A CPA is 
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 actually be a part of that 
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.  The BSI is a logical boundary 
and the 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]