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: 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]